Nem működik a weboldal a WordPress frissítése után: mit tegyen lépésről lépésre

Nem működik a WordPress a frissítés után? A leállások többsége mögött négy ok valamelyike áll: beragadt maintenance mode, bővítményütközés, inkompatibilis téma vagy kevés PHP-memória. Az első lépés mindig ugyanaz: nézze meg a weboldal adminisztrátorának e-mail-fiókját. A WordPress az 5.2-es verzió óta automatikusan észleli a végzetes PHP-hibákat, és azonnal e-mailt küld egy recovery linkkel. A legtöbb esetben FTP-hozzáférés és a kódba való beavatkozás nélkül is visszajut a weboldalára, ha a lépéseket a helyes sorrendben követi.

Miért áll le a weboldal a WordPress frissítése után?

A leggyakoribb ok egy bővítmény vagy téma inkompatibilitása a WordPress vagy a PHP új verziójával. Minden frissítés megváltoztatja a mag egyes részeit, és egy régebbi API-ra írt bővítmény nem feltétlenül működik hibátlanul az újjal. A gyakorlatban a weboldalak karbantartása során ismételten ugyanazokba a forgatókönyvekbe ütközünk:

• Bővítményütközés - az egyik telepített bővítmény a frissítés után nem kompatibilis a WP új verziójával vagy egy másik bővítménnyel.
• Inkompatibilis téma - a téma elavult függvényeket használ, amelyeket a WP új verziója eltávolított vagy megváltoztatott.
• Kevés PHP-memória - a frissítés megnövelte a memóriaigényt, és a szerver eléri a korlátot.
• Megszakadt frissítés - a mag frissítése nem fejeződött be (internetkimaradás, timeout), a weboldal maintenance mode-ban maradt.
• PHP-frissítés a szerveren - a hosting ezzel egy időben PHP-verziót váltott, és egyes bővítmények nem működnek az új verzióval.

A jó hír: mindegyik problémára van bevált megoldás. Nézze meg a tünetek táblázatát, hogy tudja, hol kezdje.

Tünet a weboldalon	Legvalószínűbb ok	Első lépés
„Briefly unavailable for scheduled maintenance” - az oldal nem jelent meg	Megszakadt frissítés, beragadt .maintenance fájl	Törölje a .maintenance fájlt a weboldal gyökérkönyvtárából
„There has been a critical error on this website”	Végzetes PHP-hiba: bővítmény vagy téma	Nézze meg az admin e-mailjét, használja a recovery linket
Fehér üres oldal (WSOD)	PHP-hiba recovery e-mail nélkül, vagy a PHP memory limit	Kapcsolja be a WP_DEBUG-ot a wp-config.php fájlban
A wp-admin működik, a front-end nem	Probléma a témával vagy egy page builder bővítménnyel	Váltson az alapértelmezett témára (Twenty Twenty-Five)
A weboldal működik, a wp-admin nem	Biztonsági bővítmény, vagy 403-as hiba a tűzfaltól	Nevezze át a plugins/ mappát FTP-n vagy fájlkezelőben

Az első lépés: a WordPress recovery mode e-mailje

A WordPress 5.2 óta érvényes: végzetes PHP-hiba esetén a rendszer azonnal e-mailt küld az adminisztrátor címére a recovery mode-ra mutató linkkel. Ez a mechanizmus közvetlenül a magba van beépítve: nem igényel bővítményt vagy különleges beállítást.

Az e-mail tárgya ehhez hasonló: „Your Site is Experiencing a Technical Issue.” Tartalma:

• A hiba leírása és a fájl, ahol keletkezett (pl. egy konkrét bővítmény).
• Link a recovery mode-hoz: egy speciális URL, amely általában egy napig érvényes.

A linkre kattintva recovery mode-ban jut be a wp-adminba. A WordPress ebben a módban csak az Ön számára blokkolja a problémás bővítményt vagy témát, a többi látogató továbbra is látja az oldalt (esetleg a hibával, de anélkül, hogy további beavatkozásokkal ártana nekik). Kapcsolja ki azt a bővítményt, amelyet az e-mail a hiba forrásaként megnevez: a weboldal általában azonnal helyreáll. A teljes mechanizmust a WordPress recovery mode hivatalos dokumentációja írja le.

Ha az e-mail nem érkezett meg, vagy nem találja, nézze meg a spam mappát. Ha ott sincs, lehet, hogy a Beállítások → Általános oldalon megadott e-mail-cím nem helyes, és ez jelzés arra, hogy a weboldal e-mail-beállításait is ellenőrizni kell. A WordPress-weboldal átfogó karbantartásáról bővebben az átfogó útmutatónkban a WordPress-weboldal karbantartásáról olvashat.

A weboldal beragadt maintenance mode-ban: így javíthatja két perc alatt

A tünet egyértelmű: az oldalon a „Briefly unavailable for scheduled maintenance. Check back in a minute.” üzenet jelenik meg. Ha ez az üzenet néhány percnél tovább látszik, a frissítés megszakadt, és a weboldal beragadt.

A mag, egy bővítmény vagy egy téma minden frissítése során a WordPress ideiglenesen létrehoz egy .maintenance fájlt a weboldal gyökérkönyvtárában. A frissítés sikeres befejezése után automatikusan törli. Ha a frissítés megszakadt, például kapcsolatkimaradás, szerveroldali timeout vagy több bővítmény egyidejű frissítése miatt, a fájl megmarad, és a weboldal magától nem áll helyre.

Lépések: a .maintenance fájl törlése

1. Jelentkezzen be a hosting cPanel felületének Fájlkezelőjébe (File Manager), vagy csatlakozzon FTP-n.
2. Lépjen be a WordPress gyökérkönyvtárába (általában public_html/ vagy a domain nevéről elnevezett mappa).
3. Jelenítse meg a rejtett fájlokat (a ponttal kezdődő fájlok alapértelmezés szerint rejtettek; a cPanelben válassza a „Show hidden files” lehetőséget).
4. Keresse meg a .maintenance fájlt, és törölje.
5. Töltse be a weboldalt a böngészőben: azonnal működnie kell.

Ha a fájlt törli, de a weboldal továbbra is hibát mutat, a frissítés valóban nem sikerült, és az ok máshol van. Folytassa a következő lépésekkel: a probléma bővítményütközés is lehet.

„Critical error” vagy fehér képernyő: hogyan kapcsolja be a debug módot

Ha a weboldal a „There has been a critical error” üzenetet vagy üres fehér oldalt mutat, és a recovery e-mail nem érkezett meg, ki kell deríteni a pontos PHP-hibát. A WordPressnek beépített debug módja van, amelyet konstansok hozzáadásával kapcsolhat be a wp-config.php fájlban.

Nyissa meg a wp-config.php fájlt a fájlkezelőben vagy FTP-n, és közvetlenül a /* That's all, stop editing! */ sor elé illessze be:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Az összes elérhető debug konstans listáját a WordPress hibakeresési dokumentációjában találja.

A WP_DEBUG_DISPLAY false beállítás biztosítja, hogy a hibák ne jelenjenek meg közvetlenül a látogatók számára az oldalon: csak a wp-content/debug.log naplófájlba íródnak. Nyissa meg ezt a fájlt, és keresse az első Fatal error vagy PHP Fatal error kezdetű sort. Ez a sor pontosan megmondja, melyik bővítmény vagy függvény okozta a problémát.

A diagnosztika után ne felejtse el kikapcsolni a debug módot: állítsa a WP_DEBUG értékét vissza false értékre, vagy törölje a sorokat. Az éles környezetben a hibakeresés csak a feltétlenül szükséges ideig tartson.

Különleges eset: PHP memory limit

Ha a debug.log az Allowed memory size of ... bytes exhausted üzenetet tartalmazza, az ok nem bővítményütközés, hanem kevés PHP-memória. A megoldás a korlát megemelése közvetlenül a wp-config.php fájlban, a define( 'WP_MEMORY_LIMIT', '256M' ); sor beillesztésével a záró megjegyzés elé. Ha a hosting csomag nem teszi lehetővé a PHP-memória legalább 256 MB-ra emelését, a probléma minden nagyobb frissítés után visszatér: ez jelzés arra, hogy a weboldal kinőtte a csomagot, és az alulméretezett.

Hogyan találja meg a problémás bővítményt vagy témát: lépésről lépésre

Ha a debug.log megmutatja a bővítmény nevét, vagy tudja, hogy az ok egy bővítményben van, de nem tudja, melyikben, haladjon rendszerezetten. A cél az, hogy a bűnöst anélkül azonosítsa, hogy feleslegesen belenyúlna az adatbázisba vagy a beállításokba.

Ha van hozzáférése a wp-adminhoz

1. Lépjen a Bővítmények oldalra, és kapcsolja ki az összes bővítményt egyszerre (jelölje ki mindet, Csoportos műveletek → Kikapcsolás).
2. Ellenőrizze, hogy működik-e a weboldal. Ha igen, a bővítményütközés igazolódott.
3. Kapcsolja be a bővítményeket egyenként, és minden bekapcsolás után ellenőrizze a weboldalt.
4. Amikor a hiba visszatér, az éppen bekapcsolt bővítmény a bűnös.
5. Hagyja kikapcsolva, lépjen kapcsolatba a bővítmény szerzőjével, vagy keressen alternatívát.

Ha nincs hozzáférése a wp-adminhoz (csak FTP vagy fájlkezelő)

1. FTP-n vagy fájlkezelővel lépjen be a wp-content/ mappába.
2. Nevezze át a plugins/ mappát plugins-off/ névre. A WordPress automatikusan kikapcsolja az összes bővítményt.
3. Ellenőrizze a weboldalt. Ha működik, az ok valamelyik bővítményben van.
4. Nevezze vissza a mappát plugins/ névre.
5. Most a plugins/ mappán belül nevezze át egyenként a bővítmények almappáit (minden bővítménynek saját almappája van), amíg meg nem találja a bűnöst.

Ha az összes bővítmény kikapcsolása nem segít, a probléma a témában lehet. Nevezze át az aktív téma mappáját (pl. a themes/tema-neve/ mappát themes/tema-neve-off/ névre): a WordPress automatikusan az alapértelmezett témát aktiválja, és a weboldalnak működnie kell. A frissítések biztonságos menetének jobb áttekintéséhez, a staging környezet használatát is beleértve, a weboldal elrontásának kockázata nélküli WordPress-frissítésekről szóló cikket ajánljuk.

A gyakorlatban a karbantartott weboldalaknál azt látjuk, hogy a leggyakoribb bűnösök a biztonsági és SEO-bővítmények: ezek hajlamosak élesebben reagálni a mag változásaira, mint az átlagos funkcionális bővítmények. Ha nem tudja, mit frissített utoljára, nézze meg a Bővítmények részben az „Utolsó frissítés” oszlopot: az ugyanazon a napon frissített bővítményeket kell elsőként ellenőrizni.

Mikor nyúljon a mentéshez, és hogyan járjon el

A mentés az utolsó mentsvár, és egyben a leggyorsabb megoldás, ha tudja, hogy létezik, és friss. Ha a weboldal összetett, sok bővítménnyel, egyedi módosításokkal vagy WooCommerce-rendelésekkel, és a diagnosztika elhúzódik, néha gyorsabb visszaállítani a frissítés előtti mentést, mint a bűnöst keresni.

A gyakorlatban ez azt jelenti, hogy minden nagyobb frissítés előtt legyen egy legfeljebb 24 órás mentése. A mentési stratégiát, a 3-2-1 szabállyal és a visszaállítás tesztelésével együtt, részletesen a WordPress mentési stratégiákról szóló cikkben írtuk le. Ha nincs mentés, és a weboldal nem működik, olyan helyzetbe kerülhet, amikor az adatbázist vagy a kódot kézzel kell javítani, ez pedig szakemberre tartozó munka.

Megelőzés: miért történik, és hogyan előzheti meg

A frissítés utáni leállás nem balszerencse, hanem annak tünete, hogy a weboldalnak nincs beállított biztonságos frissítési folyamata. A karbantartott weboldalaknál a gyakorlatban azt látjuk, hogy a tesztkörnyezet (staging) nélküli weboldalaknál lényegesen gyakoribbak a frissítés utáni problémák, mint a helyesen beállított folyamattal rendelkezőknél.

Három intézkedés, amely szinte teljesen kiküszöböli a frissítés utáni problémákat:

1. Mentés minden frissítés előtt. Az adatbázisé és a fájloké is. Mindig előtte, nem utána.
2. Frissítsen fokozatosan, ne mindent egyszerre. A magot külön, a bővítményeket egyenként: így pontosan tudja, mi okozta a problémát, ha felmerül.
3. Staging környezet a fontosabb weboldalakhoz. A frissítést először a weboldal másolatán teszteli, aztán viszi át az éles környezetbe. Webáruházas vagy egyedi módosításokat tartalmazó weboldalaknál ez a sztenderd. A WordPress-weboldal biztonsági beállításairól bővebben a WordPress-biztonság 10 pontos ellenőrzőlistájában olvashat.

Összegzés: ha nem boldogul a javítással

A WordPress-frissítés utáni leállások többsége saját erőből megoldható: recovery e-mail, .maintenance fájl, bővítmények kikapcsolása. Ha az összes lépés végigvitele után sem áll helyre a weboldal, a probléma mélyebb lehet: inkompatibilis egyedi kód, sérült adatbázis vagy szerverszintű ütközés. Ilyenkor érdemes szakemberre bízni a javítást.

Ha biztos szeretne lenni abban, hogy a weboldal frissítései a jövőben is leállás nélkül zajlanak, a havi weboldal-támogatás és karbantartás keretében minden frissítés előtt mentést készítünk, a stagingen tesztelünk, és még azelőtt kijavítjuk az esetleges ütközéseket, hogy a látogatók észrevennék őket. Kötelezettség nélküli konzultáció: szívesen megmondjuk, szüksége van-e a weboldalának ilyen gondoskodásra.

GYIK

Gyakori kérdések.

Miért jelenik meg a WordPressben a „There has been a critical error on this website” üzenet?

A WordPress ezt az üzenetet végzetes PHP-hiba esetén jeleníti meg, amelyet leggyakrabban egy inkompatibilis bővítmény vagy téma okoz. Az 5.2-es verzió óta a WordPress automatikusan e-mailt küld az adminisztrátornak egy recovery linkkel, amelyen keresztül bejut a wp-adminba, és kikapcsolhatja a problémás bővítményt.

Hogyan jutok be a wp-adminba, ha a weboldal a frissítés után nem működik?

A leggyorsabb út a WordPress e-mailjében kapott recovery link. Ha az e-mail nem érkezett meg, jelentkezzen be a hosting fájlkezelőjébe, és nevezze át a wp-content/plugins/ mappát plugins-off/ névre: a WordPress kikapcsolja az összes bővítményt, és a wp-adminnak elérhetővé kell válnia.

Mennyi idő alatt lép ki a weboldal a maintenance mode-ból a frissítés után?

Ha a frissítés sikerült, néhány másodperc alatt. Ha a weboldal tovább marad maintenance mode-ban, a frissítés megszakadt, és a gyökérkönyvtárban lévő .maintenance fájl nem törlődött automatikusan: kézzel kell törölnie FTP-n vagy fájlkezelővel.

Megéri az összes bővítményt egyszerre frissíteni?

Nem. Ha a bővítményeket egyenként frissíti, és minden frissítés után teszteli a weboldalt, probléma esetén azonnal tudja, melyik bővítmény okozta. A csoportos frissítés gyorsabb, de leálláskor az összes egyszerre frissített bővítmény között kell keresnie a bűnöst.

Mit tegyen, ha nincs mentés, és a weboldal nem működik?

Haladjon diagnosztikus módon: kapcsolja be a WP_DEBUG-ot a wp-config.php fájlban, azonosítsa a hibát okozó fájlt a debug.log alapján, és kapcsolja ki a problémás bővítményt FTP-n keresztül. Ha a weboldal az összes bővítmény kikapcsolása és a témaváltás után sem áll helyre, az ok sérült adatbázis vagy egyedi kód lehet: ilyenkor szakember segítségét javasoljuk.