Recent Post
Miksi PHP-version vaihto aiheuttaa ongelmia WordPressissä?
WordPress-sivusto saattaa toimia vuosia ilman suurempia ongelmia. Sitten palvelimelta vaihdetaan PHP:n versio ja yhtäkkiä jokin menee rikki.
Etusivu voi avautua normaalisti, mutta kirjautuminen ei toimi. Hallinta näyttää valkoista sivua. Yksi lomake ei enää lähetä tietoja. WooCommerce-kaupassa ostoskori käyttäytyy oudosti tai jokin vanha lisäosa alkaa antaa virheilmoituksia.
Ensimmäinen epäilys kohdistuu yleensä WordPressiin tai viimeksi päivitettyyn lisäosaan.
Jos ongelma alkoi täsmälleen PHP-version vaihdon jälkeen, itse PHP kannattaa kuitenkin ottaa tutkimuksessa ensimmäiseksi mukaan.
Kyse ei yleensä ole siitä, että uusi PHP-versio olisi “rikki”. Tavallisemmin vanha WordPress-koodi käyttää jotain sellaista toimintaa, joka on muuttunut, poistettu tai jonka käyttäytyminen ei ole enää sama.
Vanha koodi ei aina huomaa olevansa vanhaa
➠ WordPressin ympärillä voi olla paljon koodia, jota ei ole päivitetty pitkään aikaan.
➠ Lisäosa saattaa olla edelleen käytössä, vaikka sen kehitys on loppunut. Teemassa voi olla vuosia sitten kirjoitettuja PHP-funktioita. Sivustolle on voitu tehdä pieniä omia muutoksia, joista kukaan ei enää muista tarkasti.
➠ Kaikki tämä voi toimia vanhalla PHP-versiolla.
➠ Se ei kuitenkaan tarkoita, että koodi olisi yhteensopivaa uudemman version kanssa.
➠ Tämä on yksi PHP-version vaihdon hankalista puolista. Vanha ympäristö voi peittää ongelman pitkään.
PHP-version muutos paljastaa usein vanhan ongelman
Jos sivusto siirtyy esimerkiksi vanhemmasta PHP-versiosta uudempaan, PHP:n muuttunut toiminta voi nostaa vanhan koodin esiin.
Kyse voi olla poistetusta funktiosta, muuttuneesta oletuskäyttäytymisestä tai siitä, että aikaisemmin sivustolla ollut virhe hyväksyttiin hiljaisesti.
Uudessa ympäristössä sama kohta voi tuottaa varoituksen tai suoran virheen.
Silloin WordPress ei välttämättä näytä käyttäjälle kovin hyödyllistä tietoa. Näkyviin tulee ehkä vain:
- There has been a critical error on this website.
- Tuo viesti ei kerro, mikä tiedosto aiheutti ongelman.
- Varsinainen syy löytyy usein PHP:n virhelokista.
Lisäosa on usein ensimmäinen epäilty – eikä syyttä
Jos WordPress-sivusto hajoaa PHP-version vaihdon jälkeen, lisäosat kannattaa käydä läpi.
Erityisesti vanhat tai vähän ylläpidetyt lisäosat ovat kiinnostavia.
Lisäosa voi käyttää PHP:n toimintoa, jota uudempi versio ei enää tue. Se voi myös olettaa tietynlaisen muuttujan arvon tai tehdä kutsun, joka käyttäytyy uudessa ympäristössä eri tavalla.
Kaikki ongelmat eivät kuitenkaan johdu lisäosan iästä.
Myös aktiivisesti ylläpidetty lisäosa voi olla yhteensopimaton tietyn PHP-version kanssa. Siksi pelkkä ajatus “lisäosa on päivitetty, joten sen täytyy toimia” ei vielä todista mitään.
Teema voi olla ongelman lähde
➠ Teemat jäävät tässä keskustelussa helposti taka-alalle.
➠ Jos WordPressin hallinta toimii mutta sivuston julkinen puoli näyttää virheen, teemaa kannattaa epäillä. Erityisesti silloin, jos teemassa on paljon omaa PHP-koodia.
➠ Yksi vanha funktiokutsu voi riittää pysäyttämään sivun renderöinnin.
➠ Tilanne voi olla vielä vaikeampi, jos teeman mukana on tehty vuosien aikana omia muutoksia. Silloin ongelma ei välttämättä löydy alkuperäisestä teemasta, vaan child theme -tiedostosta tai muokatusta template-tiedostosta.
Valkoinen sivu ei tarkoita, että WordPress olisi kadonnut
PHP-version vaihdon jälkeen voi tulla vastaan niin sanottu white screen of death.
Sivu on käytännössä tyhjä.
Tällaisessa tilanteessa ei kannata aloittaa WordPressin uudelleenasennuksesta.
Jos PHP kaatuu ennen kuin WordPress ehtii muodostaa sivun, selain ei saa mitään kunnollista sisältöä näytettäväksi.
Ensimmäinen kiinnostava paikka on silloin palvelimen PHP-virheloki.
Lokista voi löytyä esimerkiksi tiedosto, rivinumero ja virheen tyyppi. Yhtäkkiä “WordPress ei toimi” muuttuu paljon tarkemmaksi ongelmaksi:
“Lisäosan X tiedostossa Y oleva PHP-kutsu kaatuu uudessa ympäristössä.”
Näiden kahden tilanteen välillä on iso ero.
Miksi kehitysympäristössä kaikki voi toimia?
Tämä aiheuttaa joskus turhaa hämmennystä.
Kehitysympäristössä käytetään PHP 8.x -versiota ja tuotannossa vanhempaa versiota. Tai päinvastoin.
Kehittäjä testaa sivustoa omalla koneellaan ja kaikki toimii. Tuotannossa sama toiminto antaa virheen.
Tässä ei välttämättä ole mitään mystistä.
PHP-version lisäksi ympäristöissä voi erota paljon muutakin: käytössä olevat PHP-laajennukset, palvelinasetukset, välimuistit ja jopa tietokannan versio.
Siksi WordPress-sivuston PHP-version pitäisi olla tiedossa myös tuotannossa, ei vain kehityskoneella.
Kaikki PHP-virheet eivät näy käyttäjälle
➠ Tuotantopalvelimella virheilmoitusten näyttäminen suoraan käyttäjälle ei yleensä ole hyvä ratkaisu.
➠ Käyttäjä tarvitsee tiedon siitä, että sivusto ei toimi.
➠ Kehittäjä tarvitsee varsinaisen virheen.
➠ Nämä ovat kaksi eri asiaa.
➠ Siksi tutkimuksessa kannattaa katsoa PHP:n ja palvelimen lokit sekä WordPressin debug-lokit. Niistä voi löytyä huomattavasti enemmän tietoa kuin selaimen näkymästä.
➠ Lokien avulla voi myös nähdä, tapahtuuko virhe jokaisella pyynnöllä vai vain tietyssä toiminnossa.
PHP-version vaihto kannattaa testata ennen tuotantoa
Paras hetki löytää yhteensopivuusongelma ei ole se hetki, jolloin tuotantosivusto on jo rikki.
Jos PHP-versiota ollaan vaihtamassa, sivustosta kannattaa tehdä testiympäristö, jossa uusi versio otetaan käyttöön ennen varsinaista muutosta.
Testauksessa ei riitä, että etusivu avautuu.
WordPress-sivuston kriittiset toiminnot pitää käydä läpi.
Esimerkiksi verkkokaupassa kannattaa testata vähintään kirjautuminen, tuotesivu, ostoskori, kassaprosessi, maksun palautuminen ja tilauksen käsittely.
Yrityksen verkkosivulla tärkeämpiä voivat olla lomakkeet, kirjautuminen, integraatiot ja sisällönhallinta.
Testattavat asiat riippuvat siis sivustosta.
PHP-version vaihtaminen ei ole sama asia kuin WordPressin päivittäminen
Nämä kaksi asiaa menevät helposti sekaisin.
WordPress, teema, lisäosat ja PHP ovat eri osia samassa ympäristössä.
Jos kaikki päivitetään samalla kertaa, ongelman jäljittäminen vaikeutuu.
Jos ensin päivitetään WordPress, sitten viisi lisäosaa ja lopuksi PHP, eikä sivusto enää toimi, vaihtoehtoja on paljon.
Jos muutokset voidaan tehdä hallitusti, vian rajaaminen on helpompaa.
Tämä ei tarkoita, että päivityksiä pitäisi jättää tekemättä. Päinvastoin. Tarkoitus on vain tietää, mitä ympäristössä muuttui.
PHP-version palauttaminen voi olla vain väliaikainen ratkaisu
➠ Kun tuotantosivusto hajoaa, ensimmäinen käytännön ratkaisu voi olla palauttaa aikaisempi PHP-versio.
➠ Se voi olla täysin järkevää, jos sivusto pitää saada nopeasti takaisin toimintaan.
➠ Mutta siihen ei kannata jäädä.
➠ Jos vanhaan PHP-versioon palataan pysyvästi vain siksi, että vanha lisäosa toimii, ongelma on siirretty myöhemmäksi. Samalla tekninen velka kasvaa.
➠ Parempi ratkaisu on selvittää, mikä koodissa ei ole yhteensopivaa uuden ympäristön kanssa ja korjata juuri se kohta.
Joskus syy ei ole PHP:ssä ollenkaan
Tämäkin on hyvä pitää mielessä.
PHP-version vaihto voi osua samaan aikaan jonkin muun muutoksen kanssa.
Palvelimella on voitu päivittää Apache tai Nginx. PHP-FPM:n asetukset ovat voineet muuttua. Cache on voinut tyhjentyä. Jokin palveluntarjoajan ympäristömuutos on voinut tapahtua samalla kertaa.
Jos ongelma alkoi saman päivän aikana, mutta PHP-version vaihto oli vain yksi useista muutoksista, kaikkia niitä pitää tarkastella.
Muuten on helppo löytää syyllinen väärästä paikasta.
Miten ongelmaa kannattaa käytännössä tutkia?
Jos WordPress alkoi oireilla heti PHP-version vaihdon jälkeen, etenisin melko suoraviivaisesti.
Ensin tarkistaisin nykyisen PHP-version ja vertaisin sitä aikaisempaan.
Sen jälkeen katsoisin PHP:n virhelokin. Jos siellä näkyy tietty lisäosa, teema tai tiedosto, tutkimus voidaan kohdistaa siihen.
Jos loki ei kerro riittävästi, seuraavaksi kannattaa rajata ongelmaa poistamalla epäilty lisäosa käytöstä testiympäristössä tai vaihtamalla hetkeksi WordPressin oletusteemaan.
Samalla kannattaa testata, koskeeko ongelma kaikkia käyttäjiä vai vain tiettyä toimintoa.
Jos sivusto toimii vanhalla PHP-versiolla mutta ei uudella, tämäkin on tärkeä havainto. Se ei vielä kerro tarkkaa syytä, mutta rajaa ongelmaa huomattavasti.
Yksi asia kannattaa tehdä ennen seuraavaa PHP-päivitystä
➠ Pidä kirjaa ympäristöstä.
➠ Ei tarvitse rakentaa valtavaa dokumentaatiota. Riittää, että tiedetään käytössä oleva PHP-versio, WordPress-versio, tärkeimmät lisäosat, teema ja mahdolliset omat integraatiot.
➠ Kun PHP-versiota myöhemmin nostetaan, muutosta voidaan verrata tähän tietoon.
➠ Silloin ei tarvitse muistella puolen vuoden päästä, mikä palvelimella oikein oli käytössä.
Lopuksi
PHP-version vaihtaminen ei yleensä riko WordPressiä itsestään.
Se tuo näkyviin yhteensopivuusongelman, joka on voinut olla ympäristössä jo pitkään.
Vanha lisäosa, teeman oma PHP-koodi tai muuttunut palvelinasetus voi toimia vuosia ilman näkyvää ongelmaa. Uusi PHP-versio muuttaa tilanteen ja yhtäkkiä sama kohta alkaa aiheuttaa virheen.
Siksi rikkinäistä WordPress-sivustoa ei kannata korjata vaihtamalla asioita yksi kerrallaan ilman tietoa siitä, mitä tapahtui.
Katso ensin mikä muuttui, tarkista lokit ja rajaa ongelma mahdollisimman pieneen osaan.
Kun PHP-version vaihto tehdään hallitusti ja yhteensopivuus testataan etukäteen, tuotantokatkos voidaan monessa tapauksessa välttää kokonaan.