Fehér képernyő vagy kritikus hiba a WordPressben: előbb olvassa el a hibát

„Kritikus hiba” vagy fehér képernyő: ugyanaz a hiba

A fehér képernyő legtöbbször végzetes PHP-hiba: a webhely egyik fájlja lehetetlent kért, és a végrehajtás leállt, mielőtt bármi megjelent volna. A WordPress 5.2 óta a WordPress elfogja ezeket a hibákat: üres oldal helyett azt írja ki, hogy „Súlyos hiba történt a webhelyünkön.”, és e-mailt küld a webhely adminisztrációs e-mail-címére. A vezérlőpulton hosszabb üzenet jelenik meg, amely így kezdődik: „Kritikus hiba történt ezen a webhelyen.”

Az oldal néhány esetben teljesen fehér marad: régebbi WordPress-verzió, a mechanizmus betöltése előtt bekövetkezett hiba, true értékre állított WP_DISABLE_FATAL_ERROR_HANDLER állandó, vagy egy gyorsítótárazó bővítmény, amely a hiba idején elmentett üres oldalt szolgálja ki. Az alábbi módszer mindegyik esetre érvényes.

Három lépés várhat addig, amíg el nem olvasta a hibát: a WordPress újratelepítése, bővítmények törlése, egy régi biztonsági mentés visszaállítása. Mindegyik törölhet beállításokat vagy friss adatokat, a hibaüzenet viszont általában megmondja, melyik összetevőt kell kikapcsolni, veszteség nélkül.

A rövidebb út: a helyreállítási mód

Amikor a WordPress elfogja a hibát, a webhely adminisztrációs e-mail-címére „[Webhely neve] A weboldalunkon technikai probléma lépett fel” tárgyú üzenetet küld. Megnevezi a hibás bővítményt vagy sablont, és tartalmaz egy linket, amely helyreállítási módban nyitja meg a vezérlőpultot.

• Ebben a módban a hibás összetevő csak az Ön számára szünetel: a látogatói továbbra is a hibát látják.
• A Bővítmények vagy a Megjelenés > Sablonok oldalon kapcsolja ki a megjelölt összetevőt, majd kattintson az adminisztrációs sávban a „Kilépés a helyreállítási módból” lehetőségre.
• A link 24 órán át érvényes, és a WordPress naponta legfeljebb egy ilyen e-mailt küld. Ha az e-mail nem érkezik meg, nézze meg a spam mappát, majd térjen át a következő módszerre.

A hiba elolvasása: a hibakeresési napló

Csatlakozzon a webhelyhez SFTP-n vagy a tárhelyszolgáltató fájlkezelőjén keresztül, nyissa meg a gyökérben lévő wp-config.php fájlt, és cserélje le a define( 'WP_DEBUG', false ); sort erre a négy sorra:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ezek a fájl szerkeszthető részét lezáró megjegyzés fölé kerülnek (magyar nyelvű WordPressen ez a /* Ennyi volt, kellemes blogolást! */ sor). Töltse újra a hibás oldalt, majd nyissa meg a wp-content/debug.log fájlt. A false értékű WP_DEBUG_DISPLAY az üzeneteket a fájlban tartja, távol attól az oldaltól, amelyet a látogatói látnak.

Ha a debug.log üres marad vagy meg sem jelenik, a hibát közvetlenül a PHP naplózta: keressen egy error_log fájlt a webhely gyökerében vagy a wp-admin mappában, vagy nézze meg a hibanaplókat a tárhelyszolgáltató kezelőfelületén.

Amit az üzenet mond, és a hozzá tartozó teendő

Egy végzetes hiba egyetlen sor: a hiba típusa, a leírása, majd in után a fájl teljes elérési útja és a sor száma. Az elérési út a leghasznosabb adat: a wp-content/plugins/név/ bővítményt, a wp-content/themes/név/ sablont jelöl.

define( 'WP_MEMORY_LIMIT', '256M' );

A hibás összetevő kikapcsolása vezérlőpult nélkül

SFTP-n vagy a fájlkezelőn keresztül

Nevezze át az üzenetben megnevezett bővítmény mappáját, például a wp-content/plugins/bovitmeny-neve mappát bovitmeny-neve.off névre. A WordPress nem találja a bővítményt, és többé nem tölti be; a beállításai az adatbázisban maradnak, és a WordPress a bővítmények oldalának következő megnyitásakor kikapcsolja.

Sablon esetén a wp-content/themes mappában lévő mappájának átnevezése újra elérhetővé teszi a vezérlőpultot, a látogatók viszont üres oldalt látnak, amíg nincs aktív sablon. Nyissa meg azonnal a Megjelenés > Sablonok oldalt: a WordPress kiírja, hogy „A jelenleg használt sablon sérült. Visszaálltunk az alapértelmezettre.”, és egy telepített alapértelmezett sablonra vált.

WP-CLI-vel

wp plugin list --status=active
wp plugin deactivate bovitmeny-neve
wp theme list
wp theme activate twentytwentyfive

Az első parancs rögzíti az aktív bővítmények listáját, ami bármilyen csoportos kikapcsolás előtt hasznos. Ha maga a WP-CLI is megáll a hibán, adja hozzá a parancshoz a --skip-plugins --skip-themes kapcsolókat: így a bővítmények és a sablon betöltése nélkül indul. A wp-content/mu-plugins mappában lévő bővítmények ekkor is betöltődnek; ha a hiba valamelyikükből ered, nevezze át a fájlját.

Ha az üzenet egyetlen összetevőt sem nevez meg, a wp plugin deactivate --all minden bővítményt kikapcsol. Ha a webhely helyreáll, kapcsolja vissza őket egyenként, minden alkalommal újratöltve a webhelyet: a hiba visszatérése előtt utoljára bekapcsolt bővítmény a hibás.

Amikor a webhely helyreállt

1. Állítsa vissza a define( 'WP_DEBUG', false ); sort, és vegye ki a WP_DEBUG_LOG sort a wp-config.php fájlból.
2. Törölje a wp-content/debug.log fájlt: a webről elérhető mappában bárki elolvashatja, és a szerver elérési útjait tartalmazza.
3. Frissítse vagy cserélje le a hibás összetevőt, a változásnaplóját elolvasva.
4. Ürítse a gyorsítótárazó bővítmény gyorsítótárát, és a tárhelyszolgáltatóét is, ha van ilyen.
5. A következő alkalomra: a frissítéseket előbb a webhely egy másolatán tesztelje, és csak utána alkalmazza élesben.