- A PHP-verzió a WordPress sebességének, biztonsági támogatottságának és bővítmény-kompatibilitásának közös alapja.
- A jelenlegi verziót az admin Helyzet oldalán és a tárhelypanelen is ellenőrizd, mert a kettő néha eltér.
- Éles váltás előtt mindig legyen teljes mentés és staging próba, utána 48 óra hibanapló-figyelés.
- Egyetlen elakadt bővítmény miatt ne maradjon a teljes oldal elavult PHP-n: cseréld, javíttasd vagy váltsd ki.
- A halasztott frissítés kamatozik: minél tovább vársz, annál nagyobb és annál drágább lesz az ugrás.
A PHP a WordPress motorja: minden egyes oldalletöltésnél ez a nyelv futtatja a magot, a sablont és az összes bővítményt. Ha a tárhelyed régi PHP-verzión jár, az oldalad lassabb, sérülékenyebb, és előbb-utóbb olyan bővítménnyel találkozol, amelyik egyszerűen nem hajlandó elindulni rajta. A frissítés viszont nem magától értetődő: rossz sorrendben végrehajtva tényleg fehér képernyőt kapsz, méghozzá élesben, a látogatók szeme előtt.
Az alábbi menetrend célja, hogy a váltás unalmas, kiszámítható karbantartás legyen, ne pedig péntek délutáni tűzoltás. A jelöléseket végig kiteszem: hol beszélek hivatalos dokumentációval igazolható tényről, hol a saját munkánk tapasztalatáról, és hol szakmai feltételezésről.
Miért számít egyáltalán, hogy melyik PHP-verzión fut az oldalad?
Rövid válasz: mert a PHP-verzió egyszerre határozza meg, milyen gyorsan válaszol a szervered, kap-e még biztonsági javítást a futtatókörnyezeted, és mennyi ideig lesz kompatibilis a bővítmény-készleted.
Hivatalosan igazolt: a PHP hivatalos verziókövetési oldala minden kiadáshoz megadja az aktív támogatás és a biztonsági támogatás lejáratát. Egy kiadás jellemzően két évig kap általános hibajavítást, utána még körülbelül egy évig kizárólag biztonsági javítást, majd életciklusa véget ér. Az életciklus végét elért verziókhoz a PHP fejlesztői közössége nem ad ki javítást, akkor sem, ha később súlyos sérülékenységre derül fény.
Hivatalosan igazolt: a WordPress saját követelmény-oldala hosszú ideje a támogatott, modern PHP-kiadásokat javasolja, és a beépített Helyzet (Site Health) modul kifejezetten figyelmeztet, ha a szervered elavult verziót futtat. A WooCommerce és a nagyobb bővítmény-készletek dokumentációja szintén minimum PHP-verziót ír elő, és ezt a küszöböt évről évre emelik.
Saját tapasztalat: a sebességkülönbség a legtöbb valós, bővítményekkel megpakolt oldalon jól érzékelhető, amikor a PHP 7-es ágról a 8-as ágra lépünk. A szerveroldali válaszidő (TTFB) jellemzően csökken, mert a nyelvi motor hatékonyabban dolgozza fel ugyanazt a kódot. Ez nem varázslat és nem garantált eredmény: ha a lassulás oka egy rosszul megírt lekérdezés vagy egy túlterhelt megosztott tárhely, a PHP-verzió önmagában nem oldja meg. Segítheti viszont, és általában az egyik legolcsóbban elérhető gyorsítás.
Szakmai feltételezés: a keresőmotorok és az AI-válaszmotorok tartalombegyűjtői korlátozott türelemmel dolgoznak. Egy lassan válaszoló szerveren a bejárás jó eséllyel ritkább és felületesebb lesz, ami közvetve az AI-válaszokban való megjelenést is befolyásolhatja. Ezt hivatalos forrás pontos számokkal nem támasztja alá, ezért feltételezésként kezeld.
Hogyan nézed meg, hogy most min futsz?
Rövid válasz: a WordPress admin Helyzet oldalán és a tárhelypanelen, mindkettőn, mert néha eltérnek.
A WordPress adminban lépj az Eszközök, majd Helyzet menüpontra, ott válaszd az Adatok fület, és nyisd le a Szerver szakaszt. A PHP verzió sorban látod a pontos kiadást, például 8.2.20. Ugyanitt megtalálod a memórialimitet, a maximális feltöltési méretet és a futásidő-korlátot is, ezekre a frissítés után szintén érdemes ránézni.
A tárhelypanelen a hely szolgáltatófüggő: cPanelben a MultiPHP Manager, Pleskben a domain melletti PHP Settings, ISPmanagerben a felhasználó PHP-beállításai adják a verziót. Saját tapasztalat: gyakran előfordul, hogy a panel a domain szintjén más verziót mutat, mint amit a WordPress lát, mert egy .htaccess bejegyzés vagy egy aldomain-szintű felülbírálás közbeszól. Ha eltérést látsz, mindig a WordPress Helyzet oldalának adata a mérvadó, hiszen az oldalad valójában azon fut.
Ha van SSH-hozzáférésed, a php -v parancs a parancssori PHP-t írja ki, ami nem feltétlenül azonos a webkiszolgáló által használttal. Pontosabb a WP-CLI-vel lekérdezni: wp eval 'echo PHP_VERSION;'. Ideiglenes phpinfo() fájlt is feltölthetsz, de a vizsgálat után azonnal töröld, mert részletes szerverinformációt szivárogtat.
Mi történik valójában, amikor fehér képernyő lesz?
Rövid válasz: a PHP végzetes hibába (fatal error) fut, a hibaüzenetek megjelenítése éles szerveren ki van kapcsolva, ezért a látogató üres oldalt kap.
A tipikus okok konkrétak és jól ismertek. Az újabb PHP-kiadásokból eltávolítottak régi függvényeket és nyelvi elemeket: a create_function(), az each(), a mysql_* függvénycsalád és a PHP 4 stílusú, osztálynévvel azonos konstruktorok mind ilyenek. A PHP 8-as ág emellett sok korábbi figyelmeztetést végzetes hibává szigorított, például amikor egy függvény rossz típusú paramétert kap. Egyetlen ilyen sor egy tíz éve nem frissített bővítményben elég ahhoz, hogy az egész oldal megálljon.
Hivatalosan igazolt: a WordPress 5.2 óta tartalmaz végzetes hiba elleni védelmet. Ha egy bővítmény vagy sablon összeomlasztja az oldalt, a rendszer levelet küld az adminisztrátor e-mail-címére egy helyreállítási móddal (recovery mode) belépő linkkel, amivel a hibás komponenst ki tudod kapcsolni. Ezért is kritikus, hogy az Beállítások, Általános oldalon szereplő adminisztrátori e-mail-cím valóban élő és olvasott legyen. Saját tapasztalat: ez a mező meglepően sok oldalon egy régi, megszűnt címre mutat, és pont akkor derül ki, amikor a legnagyobb szükség lenne rá.
A hibák láthatóvá tételéhez a wp-config.php fájlban kapcsold be a naplózást: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); és define('WP_DEBUG_DISPLAY', false);. Így a hibák a wp-content/debug.log fájlba kerülnek, a látogatók viszont nem látják őket.
Milyen menetrend szerint érdemes váltani?
Rövid válasz: hét lépésben, és a sorrend nem cserélhető fel, mert minden lépés az előzőre épül.
1. Kompatibilitási ellenőrzés
Írd össze a bővítményeidet és a sablonodat, majd nézd meg mindegyiknél a wordpress.org oldalán (vagy a fizetős termék dokumentációjában) a Requires PHP mezőt és az utolsó frissítés dátumát. Statikus kódelemzéshez a PHPCompatibility szabálykészlet a szakmai alapeszköz, WP-CLI mellett a wp plugin list --update=available gyors áttekintést ad. Saját tapasztalat: a kódelemző eszközök hajlamosak fals riasztásokra, ezért az eredményük szűrőlista, nem ítélet.
2. Elavult bővítmények kiszűrése
Amelyik bővítményt két éve nem frissítették, azt kockázatként kezeld akkor is, ha most még működik. Kérdezd meg magadtól bővítményenként: valóban használom ezt a funkciót? A tapasztalatunk szerint egy átlagos, néhány éve élő oldalon a bővítmények negyede feleslegessé vált. A frissítés előtti tisztítás a legolcsóbb kockázatcsökkentés.
3. Teljes mentés
Teljes mentés alatt fájlrendszer és adatbázis együtt értendő, letöltve a szerverről egy másik helyre. A szolgáltatói automata mentés jó, de nem elég: ha a tárhely maga hibázik, a rajta tárolt mentés is veszélyben van. Ellenőrizd, hogy a mentés visszatölthető-e, mert a soha ki nem próbált mentés csak reményt ad, biztonságot nem.
4. Staging próba
A legtöbb komolyabb tárhelyen egy kattintással készíthető staging (próba) másolat. Ott állítsd át a PHP-verziót, majd járd végig az oldal valós útvonalait: főoldal, kategórialista, terméklap, kosár, pénztár, űrlapküldés, belépés, admin felület, keresés. Webshopnál a fizetési folyamat tesztmódban is fusson végig. Saját tapasztalat: a hibák nagy része nem a főoldalon jön elő, hanem a pénztárban és az űrlapoknál, mert ott fut a legtöbb külső kódrészlet.
5. Éles váltás
A váltást a forgalmilag leggyengébb idősávra időzítsd, és soha ne pénteken vagy ünnep előtt. A tárhelypanelen állítsd át a verziót, majd azonnal ürítsd a gyorsítótárat (bővítmény-szintű cache, szerveroldali cache, ha van, CDN). Ezután nézd végig ugyanazt az útvonal-listát, amit a staging környezetben már bejártál.
6. Hibanapló-figyelés 48 órán át
A váltás utáni két nap a valódi teszt, mert ekkor futnak le az időzített feladatok, az automatikus mentések, a hírlevélküldés és a webshop háttérfolyamatai. Nézd a debug.log fájlt és a szerver hibanaplóját (cPanelben Errors, Pleskben a domain naplói), és tartsd szemmel a Search Console lefedettségi jelentését is. Szakmai feltételezés: a ritkán futó ütemezett folyamatok hibái statisztikailag itt bukkannak fel, nem a váltás első órájában.
7. Visszaállási terv
A visszaállás menete legyen leírva még a váltás előtt, egy oldalon: ki állítja vissza a PHP-verziót, hol van a mentés, milyen jelszavakkal, és melyik ponton hozunk döntést. A PHP-verzió visszaállítása önmagában általában egy kattintás, és a legtöbb esetben azonnal megszünteti a hibát. Adatbázis-visszatöltésre csak akkor van szükség, ha közben tartalom vagy rendelés is sérült.
Mit tegyél, ha egy régi bővítmény vagy sablon nem indul el?
Rövid válasz: előbb azonosítsd pontosan a hibás komponenst, utána négy út közül válassz, és ne az egész oldalt tartsd vissza egyetlen bővítmény kedvéért.
Az azonosítás a hibanapló utolsó soraival kezdődik: ott szerepel a fájl teljes elérési útja, ami elárulja, melyik bővítmény vagy sablon mappájáról van szó. Ha az admin felület sem érhető el, FTP vagy fájlkezelő segítségével nevezd át a gyanús bővítmény mappáját (például plugin-neve helyett plugin-neve-off), ettől a WordPress kikapcsolja. Ez a legmegbízhatóbb kézi módszer, ha a helyreállítási mód nem elérhető.
Ezután a lehetőségek: frissítsd a bővítményt, mert lehet, hogy létezik újabb, kompatibilis kiadás. Ha nincs, keresd meg a fejlesztőt, és kérdezz rá a tervezett támogatásra. Ha a válasz nemleges vagy nem jön válasz, keress kiváltó megoldást, jellemzően minden elterjedt funkcióhoz létezik karbantartott alternatíva. Végső esetben egy fejlesztő megjavíthatja a konkrét sort, ez viszont saját karbantartási felelősséget teremt, amivel előre számolj.
Ha a sablon az akadály, a helyzet komolyabb, mert a sablon a teljes megjelenést viszi. Ilyenkor a köztes lépcső gyakran működik: a PHP 7.4-ről nem egyből a legújabb kiadásra lépsz, hanem egy köztes verzióra, ami időt ad a sablon cseréjének megtervezésére. Saját tapasztalat: a sablonváltás szinte mindig nagyobb projekt, mint amekkorának elsőre látszik, ezért érdemes külön ütemezni, nem a PHP-frissítés napjára tolni.
Miért kamatos kockázat a halasztott PHP-frissítés?
Saját nézőpont: a PHP-frissítés halasztása pontosan úgy viselkedik, mint egy kamatozó tartozás. Ha évente lépsz egyet, minden alkalommal egy-két apró változással kell megküzdened, amit fél nap alatt le lehet tesztelni. Ha öt évig nem nyúlsz hozzá, egyszerre kell átugranod több nagy kiadást, ahol a nyelv több elemet eltávolított és több figyelmeztetést szigorított végzetes hibává. Az ugrás mérete nem lineárisan, hanem meredekebben növeli a hibalehetőségek számát.
Ehhez jön a második kamat: minél régebbi a PHP-verziód, annál régebbiek maradnak a bővítményeid is, mert az újabb kiadásaik már nem telepíthetők rád. Így nemcsak egy PHP-frissítés torlódik fel, hanem egy teljes bővítmény-generáció is. Szakmai feltételezés: a valóban fájdalmas WordPress-frissítések többsége nem a technika miatt nehéz, hanem azért, mert több év elhalasztott karbantartása érkezik meg egyszerre.
A gyakorlati következtetés egyszerű: tedd naptárba. Évente egyszer, kiszámítható időpontban, staging környezetben átnézve a PHP-frissítés rutinfeladat marad, nem projekt.
Mi legyen a 10 pontos ellenőrzőlistádon?
- Írd fel a jelenlegi PHP-verziót az admin Helyzet oldaláról és a tárhelypanelről is, és jegyezd fel az eltérést, ha van.
- Ellenőrizd, hogy az adminisztrátori e-mail-cím élő, mert a helyreállítási mód levele oda érkezik.
- Frissítsd a WordPress magot, a sablont és minden bővítményt a legfrissebb kiadásra, még a PHP-váltás előtt.
- Nézd át bővítményenként a Requires PHP mezőt és az utolsó frissítés dátumát, és jelöld meg a kétévnél régebbieket.
- Töröld a valóban nem használt bővítményeket, ne csak kapcsold ki őket.
- Készíts teljes mentést (fájl és adatbázis) egy külső helyre, és ellenőrizd a fájlméretet, hogy nem üres-e.
- Kapcsold be a naplózást a
wp-config.phpfájlban, megjelenítés nélkül. - Futtasd végig a teljes útvonal-listát staging környezeten az új PHP-verzión, a pénztárral és az űrlapokkal együtt.
- Élesben válts alacsony forgalmú időben, ürítsd az összes gyorsítótárat, és ismételd meg az útvonal-tesztet.
- Figyeld a hibanaplót 48 órán át, és tartsd kéznél a leírt visszaállási tervet.
Ha ez a tíz pont megvan, a fehér képernyő esélye jó eséllyel a minimumra csökken. Garanciát senki nem adhat rá, mert minden oldal más kódot futtat, de a fenti sorrend a hibák túlnyomó részét még azelőtt kiszűri, hogy éles környezetbe érnének.
Források és további olvasnivalók
- PHP hivatalos dokumentáció: Supported Versions és Migration guide (php.net)
- WordPress.org: Requirements és Site Health dokumentáció
- WordPress Developer Resources: Debugging in WordPress (WP_DEBUG, WP_DEBUG_LOG)
- WordPress Developer Resources: Fatal Error Protection és Recovery Mode
- WP-CLI hivatalos kézikönyv
- PHPCompatibility szabálykészlet dokumentációja (PHP_CodeSniffer)
- Google Search Central: Crawling and indexing, valamint a Core Web Vitals dokumentáció
- WooCommerce hivatalos szerverkövetelmény-dokumentáció
Gyakori kérdések
Melyik PHP-verziót válasszam, ha ma frissítenék?
Általános szabály: a hivatalosan még aktív támogatás alatt álló kiadások közül a legmagasabbat, amit a bővítményeid és a sablonod dokumentáltan támogatnak. A php.net verziókövetési oldalán ellenőrizd a friss lejárati dátumokat, mert ezek évente változnak. Ha a sablonod csak egy régebbi kiadást bír, köztes lépcsőként arra válts, és tervezd be a sablon cseréjét.
Elveszhet tartalom vagy rendelés a PHP-frissítés miatt?
A PHP-verzió váltása önmagában nem nyúl az adatbázishoz, ezért közvetlen adatvesztést nem okoz. A kockázat közvetett: ha az oldal órákig hibás állapotban van, az alatt beérkező rendelés vagy űrlapküldés meghiúsulhat. Ezért érdemes alacsony forgalmú időben váltani, és teljes mentéssel a kezedben.
Miért nem látok semmilyen hibaüzenetet, csak üres fehér oldalt?
Éles szervereken a hibaüzenetek megjelenítése biztonsági okból ki van kapcsolva, ezért a végzetes hiba üres válaszként érkezik meg. Kapcsold be a naplózást a wp-config.php fájlban a WP_DEBUG és WP_DEBUG_LOG konstansokkal, a WP_DEBUG_DISPLAY értékét pedig hagyd hamisan, így a hiba a debug.log fájlba kerül.
Mennyi időt vegyek rá egy átlagos oldalnál?
Saját tapasztalatunk szerint egy közepes méretű bemutatkozó oldalnál a teljes menetrend (ellenőrzés, mentés, staging teszt, éles váltás) néhány óra munkát jelent, plusz a 48 órás megfigyelés, ami már nem folyamatos jelenlét. Webshopnál számolj lényegesen többel, mert a fizetési és szállítási folyamatot végig kell tesztelni.
Meg kell-e várnom, amíg minden bővítményem hivatalosan támogatja az új verziót?
Nem feltétlenül, mert sok jól karbantartott bővítmény működik olyan verzión is, amit a leírásában még nem tüntettek fel. A staging próba pont erre való: ott derül ki tényszerűen, mi működik. Ha viszont egy bővítmény már ott is elszáll, azt még az éles váltás előtt kezelni kell.
Mi van, ha a tárhelyszolgáltatóm magától frissíti a PHP-t?
Egyre több szolgáltató jelenti be előre a kényszerfrissítést, jellemzően levélben. Ilyenkor a fenti menetrendet a megadott határidő előtt kell végigvinned, mert a váltás megtörténik akkor is, ha nem készültél fel rá. Ha a levél már megérkezett, a kompatibilitási ellenőrzéssel és a mentéssel kezdd.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.