A WordPress hibakeresési módját három állandó vezérli a wp-config.php fájlban. A WP_DEBUG a főkapcsoló; a WP_DEBUG_LOG fájlba írja a hibákat, a WP_DEBUG_DISPLAY pedig az oldalra. Amíg a WP_DEBUG ki van kapcsolva, a másik kettő hatástalan.

Egy fontos alapérték okozza a legtöbb meglepetést: a WP_DEBUG_DISPLAY értéke magától true. Ha valaki csak a WP_DEBUG állandót kapcsolja be, a PHP figyelmeztetései a látogatók előtt is megjelennek, a szerver elérési útjaival együtt. Éles webhelyen ez a beállítás a biztonságos: a WP_DEBUG be, a WP_DEBUG_DISPLAY ki, a WP_DEBUG_LOG pedig egy webről nem elérhető fájlba ír.

Mit csinál az egyes állandó?

WP_DEBUG. Ha true, a PHP minden figyelmeztetést, megjegyzést és elavultsági jelzést is jelent, és a WordPress az elavult függvények használatát is hibaként jelzi. Ha false (ez az alapérték), csak a súlyos hibák kerülnek naplózásra.

WP_DEBUG_DISPLAY. Ha true vagy nincs megadva, a hiba megjelenik az oldal HTML-jében. Ha false, nem jelenik meg. A REST API-, AJAX- és XML-RPC-kéréseknél a WordPress a megjelenítést mindig kikapcsolja, hogy a hibaüzenet ne rontsa el a JSON-választ; ha a hibát az oldalon látja, a REST-válaszban viszont nem, az tehát szándékos.

WP_DEBUG_LOG. Ha true, a hibák a wp-content/debug.log fájlba kerülnek. Ez a fájl a webről is letölthető, bárki megnyithatja, aki kitalálja a címét, és teljes szerverútvonalakat, néha adatbázis-részleteket is tartalmaz. Ha a true helyett egy abszolút útvonalat ad meg, a WordPress oda ír, és így a naplót a public_html mappán kívülre teheti. Ha false, a WordPress nem módosít a naplózáson, és a hibák a tárhely saját PHP-naplójába kerülnek.

SCRIPT_DEBUG. Nem PHP-hibákról szól: a WordPress a saját JavaScript- és CSS-fájljainak tömörítetlen változatát tölti be, így a böngésző konzoljában olvasható sorra mutat a hiba. A bővítmények saját, tömörített fájljaira többnyire nincs hatással.

Hol vannak a hibák az aWh cPanel tárhelyén?

A cPanel tárhelyeken a PHP alapból a home könyvtár logs/php.error.log fájljába naplóz, tehát a súlyos hibákat akkor is megtalálja, ha a WordPress hibakeresési módja ki van kapcsolva. A webhely gyökerében egy error_log fájl is keletkezhet. Mindkettőt megnyithatja a Fájlkezelőben vagy a Terminalban:

tail -n 20 ~/logs/php.error.log

Ha a naplóban nincs semmi, vagy a figyelmeztetésekre is kíváncsi, kapcsolja be a hibakeresési módot. A naplóbejegyzések értelmezéséről blogcikkünk ír részletesen.

A hibakeresési mód bekapcsolása

A WP Toolkitben

A cPanel WordPress Management felületén nyissa meg a webhely kártyáját, és az Eszközök résznél kapcsolja be a Hibaelhárítás kapcsolót. Ha végzett, kapcsolja ki.

WP-CLI-vel

Előbb mentse el a wp-config.php fájlt, mert egy elírás az egész webhelyet leállítja:

cd ~/public_html
cp -p wp-config.php ~/wp-config.php.bak-$(date +%F)
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set WP_DEBUG_LOG /home/felhasznalonev/logs/wp-debug.log

A --raw kapcsoló a logikai értéket idézőjelek nélkül írja be; az útvonalnál hagyja el, mert annak idézőjelben kell lennie. A felhasznalonev helyére a cPanel-felhasználónevét írja (a whoami parancs kiírja). A WP-CLI az új állandókat a megfelelő helyre szúrja be, és ha a fájlban már van WP_DEBUG sor (a WP Toolkit által telepített webhelyeken van), azt módosítja. A WP-CLI alapjait a WP-CLI használatáról szóló cikk írja le.

Kézzel, a Fájlkezelőben

Nyissa meg a wp-config.php fájlt szerkesztésre, keresse meg a meglévő WP_DEBUG sort, és cserélje le erre a három sorra:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/felhasznalonev/logs/wp-debug.log' );

A soroknak a /* That's all, stop editing! Happy publishing. */ megjegyzés fölött kell lenniük. Ami a fájl végén lévő require_once ABSPATH . 'wp-settings.php'; sor alá kerül, az már túl későn fut le, és hatástalan. Egy állandót csak egyszer adjon meg: ha a fájlban kétszer szerepel, a PHP figyelmeztet, és az első érvényes.

Ellenőrzés

wp eval 'var_dump( WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, ini_get( "error_log" ) );'

A válasz a teszt-webhelyünkön:

bool(true)
string(38) "/home/felhasznalonev/logs/wp-debug.log"
bool(false)
string(38) "/home/felhasznalonev/logs/wp-debug.log"

Az utolsó sor bizonyítja, hogy a WordPress a beállítást ténylegesen alkalmazta. Ezután töltse be a hibás oldalt, és nézze meg a naplót:

tail -n 20 ~/logs/wp-debug.log

Végül ellenőrizze, hogy az oldalon semmi nem jelenik meg:

curl -s https://pelda.hu/ | grep -icE "Warning:|Notice:|Deprecated:|Fatal error:"

A helyes válasz 0. Ha nagyobb szám, valami később visszakapcsolja a megjelenítést; többnyire egy bővítmény. Megkeresheti így: grep -rn "display_errors" ~/public_html/wp-content/plugins/.

Ha a napló üres marad

1. Az állandók rossz helyen vannak. Hasonlítsa össze a sorszámokat: grep -n "wp-settings\|WP_DEBUG" wp-config.php. A WP_DEBUG soroknak kisebb sorszámúnak kell lenniük.
2. Elírás van az útvonalban. Egy elgépelt útvonal is érvényes szöveg, a WordPress beállítja, a PHP pedig csendben nem tud oda írni. Ellenőrizze, hogy a mappa létezik.
3. Valami felülírja a beállítást. Ha az ini_get( "error_log" ) nem az Ön útvonalát adja vissza, egy bővítmény vagy egy must-use bővítmény (wp-content/mu-plugins) módosítja.
4. A folyamat a PHP előtt állt le. Ha az oldal üres 500-as hibát ad, és egyik naplóban sincs semmi, a kérés nem jutott el a PHP hibakezeléséig. Ilyenkor a cPanel Mutató csoportjában a Hibák oldalt, és a CloudLinux erőforráslimiteket érdemes megnézni.

Ne maradjon bekapcsolva feleslegesen

A WordPress és a PHP nem forgatja a naplót. Egy bővítmény, amely minden oldalbetöltésnél ugyanazt az elavultsági jelzést írja ki, napok alatt gigabájtos fájlt hoz létre, amely a tárhelyét és a fájlok számát (inode) is fogyasztja. A hiba felderítése után:

• kapcsolja ki a WP_DEBUG állandót (wp config set WP_DEBUG false --raw) vagy a WP Toolkit Hibaelhárítás kapcsolóját;
• a napló tartalmát ne törölje, hanem ürítse: : > ~/logs/wp-debug.log, majd ha már nincs rá szüksége, törölje a fájlt;
• ha a napló tele van ugyanazzal a figyelmeztetéssel, azt a bővítményt vagy sablont kell javítani vagy lecserélni; az üzenetek elrejtése csak a tünetet tünteti el.

A hibakeresési mód kizárólag PHP-hibákat mutat: a lassú adatbázis-lekérdezést vagy a memóriakorlát közelségét nem. Ha a webhely lassú, a WordPress gyorsításáról szóló cikk és a memóriakorlátról szóló cikk segít; a fehér képernyő hibakeresését pedig külön cikk írja le.