Mulla on vanhempi sovellus, joka on tehty joskus PHP 5.3 version aikaan. Nyt webhotelli päivitti sivusonsa ja PHP 7.0 on tullut tilalle. Nyt tuo vanhempi sovellus ei toimi enää. Esim. mysql_connect() ei ole enää mahdollinen komento.
Onko tietoa, mitä kaikkea pitäisi tehdä, että tietokantayhteys ja -haku toimisi kunnollisesti PHP 7 versiolla?
Päivitä yhteys esim. Putkan oppaan mukaan PDO-rajapintaan tai vaihtoehtoisesti mysqli-rajapintaan. Päivitysohjeita on varmasti netissä useita vuosien varrelta, kun PHP 7 on jo aika muinainen versio. On myös tehty yhteensopivuuskirjastoja, kurkkaa vaikka mysql2mysqli, josta näkee, että mysqli on aika helppo päivitysratkaisu, jos haluaa minimivaivalla saada vanhan koodin toimimaan.
Päivitä ihmeessä myös webhotellia, PHP 7 on jo aikaa sitten pudonnut tuetuista versioista ja nyt pitäisi olla esim PHP 8.3.
Kiitos nopeasta vastauksesta! Tuossa oli, että mysql_connect() muokataan mysqli_connect() -muotoon alla olevan mukaisesti. Sitten pitäisi kai toimia ..
function mysql_connect($server, $username, $password, $new_link = FALSE, $client_flags = 0)
{
if (is_null($server)) $server = ini_get("mysql.default_host");
if (is_null($username)) $username = ini_get("mysql.default_user");
if (is_null($password)) $password = ini_get("mysql.default_password");
list($host, $port) = explode(":", $server);
if (empty($port)) $port = 3306;
return mysql_active_link(mysqli_connect($host, $username, $password, "", $port), TRUE);
}Hmm. Hotellin palvelinpäivityksen yhteydessä koko tietokanta katosi bittiavaruuteen :( Ovat yrittäneet nyt pari päivää saada palautettua sitä, mutta eivät ole vielä onnistuneet .. Oma varmuuskopio on vuodelta 2017 :(
Siis pelkästään connect-funktion vaihtaminen ei suinkaan riitä, vaan myös kaikki muut tietokantafunktiot pitää korvata uusilla.
TapaniS kirjoitti:
Nyt webhotelli päivitti sivusonsa ja PHP 7.0 on tullut tilalle.
TapaniS kirjoitti:
Hmm. Hotellin palvelinpäivityksen yhteydessä koko tietokanta katosi bittiavaruuteen :( Ovat yrittäneet nyt pari päivää saada palautettua sitä, mutta eivät ole vielä onnistuneet .. Oma varmuuskopio on vuodelta 2017 :(
Kerro nyt ihmeessä mikä hotelli kyseessä :)
Saako kysyä kuinkas tärkeää dataa palvelimella oli, kun se on noinkin vanhalla php:lla pyörinyt?
Lebe80 kirjoitti:
Saako kysyä kuinkas tärkeää dataa palvelimella oli, kun se on noinkin vanhalla php:lla pyörinyt?
Onneksi tää oli vaan tämmöinen oma harjoitteluprojekti. Mutta hyvä muistutus, miksi varmuuskopioita kannattaa tehdä!
pevm kirjoitti:
Kerro nyt ihmeessä mikä hotelli kyseessä :)
Tämmöistä voi sattua missä vaan eli jääköön toistaiseksi vielä nimeämättä.
TapaniS kirjoitti:
Tämmöistä voi sattua missä vaan eli jääköön toistaiseksi vielä nimeämättä.
No, toki aina voi tapahtua sellaisessakin jota pyritään erittäin ammattimaisesti pyörittämään, kuten OVH:lla 2021. Hekin joutuivat korvaamaan asiakkaille 400 000 euroa, kun tulipalo tuhosi datakeskusta ja osalla asiakkaista meni myös varmuuskopiot.
Toisaalta ehkä olit ostanut palvelua joka "ei sisällä varmuuskopiointia" niin kai tuo sitten on jossain määrin ok.
Grez kirjoitti:
(08.05.2024 10:07:28): ”– –” No, toki aina voi tapahtua sellaisessakin...
Kaippa tässä tapauksessa pitäisi pystyä todistamaan, että on sattunut taloudellista vahinkoa, jota varten korvauksia pitäisi maksaa. Ei Suomessa mitään periaatteen vuoksi mitään korvata.
Joo siis pointtini ei nyt ollutkaan että pitäiskö TapaniS:n saada korvauksia vaan siinä että joskus datan katoamista tosiaan "voi sattua missä vaan" vaikka olisi ostettu ja hoidettu varmuuskopioinnitkin.
Tietokanta saatiin palautettua ja kaikki toimii taas! Tosin php-versio ja Sgl -komennot ovat vielä päivittämättä (palvelimelta valittu nyt php 5.3).
Latasin myös tuoreen varmuuskopion itselleni :)
---
Edit: Nyt lähti toimimaan!
$yhteys = mysqli_connect($ini['server'],$ini['user'],$ini['pwd'],$ini['dbase']);
Sain tietokannan toimimaan PHP 8.3 -versiolla, mutta toinen sovellus meni rikki. Se toimii ainakin PHP 7.0 -versiolla.
Osaisiko joku tietää, mikä muutos PHP 7.0 -> 8.3 versioon voisi aiheuttaa sivun kaatumisen? Onko muilla ollut vastaavia ongelmia? Tuossa ei ole tietokantakomentoja lainkaan mukana, mutta tietoja luetaan (ja kirjoitetaan) ainakin palvelimella olevista tekstitiedostoista. Voisiko tuo aiheuttaa ongelman?
$file_contents = file_get_contents($team1fileZ); $fh = fopen($team1fileZ, "w"); $file_contents = str_replace($dataRow1,$dataRow2,$file_contents); fwrite($fh, $file_contents); fclose($fh);
Toinen mahdollisuus voisi olla esim. tietojen noutaminen www-sivulta:
function file_get_contents_curl( $url ) {
$ch = curl_init();
curl_setopt( $ch, CURLOPT_HEADER, 0 );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch, CURLOPT_URL, $url );
$data = curl_exec( $ch );
if(curl_errno($ch)){
echo 'Curl error: ' . curl_error($ch);
}
curl_close( $ch );
return $data;
}PHP:n sivuilla on kattavat listat eri versioiden välisistä muutoksista, joiden perusteella voi vikaa etsiä. Joissain funktioissa on muutoksia, ja lisäksi yksi aika merkittävä muutos on, että null ei kelpaa tyhjäksi merkkijonoksi funktioille.
Ei koodia debugata arvaamalla. Laita PHP:n virheilmoitukset näkyviin, niin luulisi vian löytyvän parissa sekunnissa.
Metabolix kirjoitti:
..
Ei koodia debugata arvaamalla. Laita PHP:n virheilmoitukset näkyviin, niin luulisi vian löytyvän parissa sekunnissa.
Joo kiitokset taas! Tuolta löytyi, että olen käyttänyt "ZWNBSP" -merkkiä trim -funktiossa. Se ei toimi enää PHP 8.3 -versiossa. Pitää etsiä toinen konsti tuohon ..
Tuolta näyttäisi löytyvän jotakin selitystä ..
Löytyi tämmöinen, antaakohan tää saman lopputuloksen? No pitää varmaan koettaa .. :)
$output = trim($line, "\\xef\\xbb\\xbf");
Vielä kaatui tämmöiseen checkbox -juttuun:
if($_POST[$playVar].checked){ ...
Lähti toimimaan, kun muutin näin:
if($_POST[$playVar]){ ...
(Laitan sillä näkyville, jos jollakin toisellakin ois näitä samoja ongelmia.)
Nyt palvelimella PHP 8.3 ja kaikki toimii! :)
TapaniS kirjoitti:
Vielä kaatui tämmöiseen checkbox -juttuun:
if($_POST[$playVar].checked){ ...
Onni, että kaatui. Koodissa on ollut logiikkavirhe ilmeisesti jo 20 vuotta.
PHP:ssä piste yhdistää merkkijonoja. Tässä on selvästi koodarilla ollut täysin väärä käsitys pisteen käytöstä.
Vanhalla PHP-versiolla vakion näköiset sanat tulkittiin vastaavaksi merkkijonoksi, eli checked == "checked", ellei ole muuta määritelty. Niinpä tuossa lausekkeen arvo on ollut tyhjän laatikon tapauksessa "checked" (eli tosi) ja täyden laatikon tapauksessa esim. "1checked" (eli myös tosi). Sittemmin määrittelemättömät vakiot on kielletty, ja nyt onneksi virhe on pakko korjata.
// Tässä on vielä vika demonstroituna:
<?php $foo = array(); $bar = "a"; var_dump($foo[$bar].checked); // PHP 7.1: // Notice: Use of undefined constant checked - assumed 'checked' // string(7) "checked" // PHP 7.2: sama mutta Warning. // PHP 8.0: Fatal error: Uncaught Error: Undefined constant "checked"
Jos tuo lähetetty arvo kuvastaa checkboxia, tarkistukseen sopii vaikka isset:
Ja edelleenkin, laita ne virheilmoitukset käyttöön.
Kiitokset hyvistä vinkeistä!
Noissa sovelluksissa on vähän se vika, että jos kaikki toimii, niin niitä ei kannata "korjata". Eli nää kyllä siis toimi moitteetta PHP 5.3 -ympäristössä, mutta ei enää näissä uudemmissa. No nyt näyttäisi kuitenkin taas kaikki toimivan :) :) :)
TapaniS kirjoitti:
Tuolta löytyi, että olen käyttänyt "ZWNBSP" -merkkiä trim -funktiossa. Se ei toimi enää PHP 8.3 -versiossa.
Miten olet käyttänyt ZWNBSP-merkkiä, miten se ei nykyään toimisi? Tässä asiassa ei pitäisi olla merkittävää muutosta aiempaan.
Voin taata, että löytämäsi rivi ei toimi samoin, koska siinä on tupla-\\ ja se päätyy siis poistamaan alusta ja lopusta merkit \, x, b, e, f.
<?php $line = "be\\\\bbe\\xefb:keskiosa:\\xefbbexb\\exb\\ex"; $output = trim($line, "\\xef\\xbb\\xbf"); var_dump($output); // string(10) ":keskiosa:"
Ensiksi tulee ehkä mieleen korjata vaihtamalla \\:n tilalle yksi \. Kuitenkin PHP:n perusfunktiot käsittelevät tavuja eivätkä merkkejä, joten esimerkiksi trim ei sovellu ASCII:n ulkopuolisten merkkien muokkaamiseen: se voi poistaa myös osittaisia Unicode-merkkejä, jolloin merkkijono on viallinen. Esimerkiksi jos merkkijono päättyisi merkkiin λ (lambda), tuo trim "korjattuna" pyyhkisi tästä jälkimmäisen tavun pois.
<?php $line = "lambda = λ"; $output = trim($line, "\xef\xbb\xbf"); var_dump(json_encode($output)); // bool(false); merkkijono on rikki, JSON-enkoodaus epäonnistuu.
Järkeviä vaihtoehtoja kokonaisen Unicode-merkin poistamiseen (riippuen tarkasta tavoitteesta) ovat esim. str_replace tai preg_replace tai pitemmin str_starts_with ja substr.
$output = str_replace("\xef\xbb\xbf", "", $line); // Poistaa kaikki ZWNBSP:t.
TapaniS kirjoitti:
Eli nää kyllä siis toimi moitteetta PHP 5.3 -ympäristössä,
No mutta onhan se selvää, että jos checkboxin arvo jää tosiasiassa tarkistamatta, ohjelma ei ole varmaan toiminut "moitteetta". Olisiko tämmöisessä koodissa syy, miksi joistain paikoista tulee spammia, vaikka takuulla on jättänyt markkinointiluvat klikkaamatta.
Myös "moitteettomassa" ympäristössä kannattaa laittaa kaikki PHP:n ilmoitukset menemään lokiin ja kannattaa ne korjata. Esimerkiksi tuo checked-virhe on aiheuttanut huomautuksen jo muinaisista ajoista lähtien ja sen olisi voinut korjata jo alkujaan.
Metabolix kirjoitti:
$output = str_replace("\xef\xbb\xbf", "", $line); // Poistaa kaikki ZWNBSP:t.
Korjasin vielä tuon, eikä mikään mennyt rikki. Hyvältä näyttää!
Jäi vielä sanomatta, että mulla siis oli checkbox -chekki ennen tuota virheellistä riviä, joten se selittää, miksi on toiminut.
Tää on siis vanha virheellinen koodi, jossa on kahteen kertaan yritetty tehdä sama asia :( Logiikka oli ensin varmistaa, löytyykö boxi ja sitten, onko se ruksattu. Ilmeisesti se on kuitenkin ruksattu, jos se löytyy. Tuplamoka antoi oikean lopputuloksen.
TapaniS kirjoitti:
lmeisesti se on kuitenkin ruksattu, jos se löytyy.
Näin on, tyhjiä checkboxeja ei lähetetä.