Minden WordPress-tulajdonos rémálma a “halál fehér képernyője” vagy egy váratlanul összeomló bővítmény. Ilyenkor jön a pánik, a találgatás és a kísérletezés. Pedig a megoldás ott rejtőzik a rendszer mélyén: ez a WP_DEBUG.

Ez egy beépített eszköz, amely arra szolgál, hogy láthatóvá tegye a WordPress “gondolatait”. Amikor bekapcsolod, a rendszer abbahagyja a hibák elrejtését, és konkrét üzenetekben közli veled, hogy pontosan melyik fájl melyik sorában csúszott el a folyamat.

Hogyan kapcsold be? A wp-config.php titka

A hibakeresés aktiválásához a weboldalad szívébe, a wp-config.php fájlba kell egy apró módosítást eszközölnöd. Ezt megteheted FTP-n keresztül vagy a tárhelyed fájlkezelőjében.

  1. Keresd meg a fájlt: A weboldalad gyökérkönyvtárában találod a wp-config.php-t.
  2. Keresd meg a bűvös sort: Görgess lefelé, amíg meg nem találod a következőt: define( ‘WP_DEBUG’, false );
  3. Válts át élesbe: Írd át a false értéket true-ra: define( ‘WP_DEBUG’, true );

Amint elmented, a weboldalad elkezdi kiírni a hibaüzeneteket a felületre.

A három testőr: DEBUG, LOG és DISPLAY

A profi hibakeresés nem merül ki ennyiben. Van két hűséges társa a WP_DEBUG-nak, amiket érdemes ismerned:

  • WP_DEBUG_LOG: Ha ezt bekapcsolod (true), a hibák nem csak a képernyőn (vagy ott sem) jelennek meg, hanem belekerülnek egy debug.log fájlba a wp-content mappán belül. Ez azért zseniális, mert később is nyugodtan átnézheted a listát.
  • WP_DEBUG_DISPLAY: Ha nem akarod, hogy a látogatóid is lássák a kódhibákat a weboldaladon, ezt állítsd false-ra. Így a hibák csak a háttérben, a log fájlban gyűlnek, az oldalad pedig “tiszta” marad.

Egy profi beállítás így fest a fájlban:

define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );

További hasznos eszközök a hibavadászathoz

Bár a WP_DEBUG a legfontosabb alapkövünk, a WordPress fejlesztői közössége egyéb beépített funkciókat is biztosít a speciálisabb problémák feltérképezésére:

  • SCRIPT_DEBUG: Ez a beállítás arra kényszeríti a WordPress-t, hogy a beépített JavaScript és CSS fájlok fejlesztői verzióit használja a tömörített (minified) változatok helyett. Ez akkor életmentő, ha azt gyanítod, hogy egy alapvető script vagy stíluslap módosítása okozza a hibát az oldalon.
  • SAVEQUERIES: Ha az oldalad gyanúsan lassú, ez a funkció minden egyes adatbázis-lekérdezést elment egy tömbbe. Így pontosan láthatod, melyik lekérdezés mennyi ideig tartott, és melyik funkció hívta meg azt, ami segít a szűk keresztmetszetek azonosításában.

Hol van a kód? – Ha nem találod, hozd létre!

Sokszor előfordul, hogy izgatottan megnyitod a wp-config.php fájlt, végigpörgeted a sorokat, és… semmi. Nem látod a WP_DEBUG kifejezést sehol. Ne aggódj, ez teljesen normális! Alapértelmezés szerint a WordPress nem minden esetben tartalmazza ezeket a sorokat a fájlban. Ilyenkor neked kell manuálisan „beültetned” őket.

Hova illeszd be? Ez a legfontosabb kérdés. A wp-config.php fájl végén van egy sor, ami így hangzik: /* That’s all, stop editing! Happy publishing. */ (Vagy magyarul: „Ennyi volt, ne szerkessz tovább! Jó publikálást!”)

Mindenképpen ezen sor fölé illeszd be a kódot! Ha a fájl legvégére teszed, előfordulhat, hogy nem fog működni, mert a rendszer addigra már betöltötte a beállításait.

Így nézzen ki a beillesztés:

// Hibakeresés engedélyezése

define( ‘WP_DEBUG’, true );

// Hibák mentése a /wp-content/debug.log fájlba

define( ‘WP_DEBUG_LOG’, true );

// Hibák elrejtése a látogatók elől (csak a fájlba írjon)

define( ‘WP_DEBUG_DISPLAY’, false );

/* That’s all, stop editing! Happy publishing. */

Mi a teendő, ha már ott van a sor?

Ha a fájlban már szerepel a define( ‘WP_DEBUG’, false ); sor, akkor nincs dolgod a másolással. Ilyenkor csak a bűvös szót kell kicserélned: a false (hamis) értéket írd át true-ra (igaz). Ezzel máris felkapcsoltad a villanyt a sötét szobában.

Miért jobb a fájlba mentés, mint a képernyő?

A WP_DEBUG_LOG bekapcsolása a legbiztonságosabb módszer. Ekkor nem a weboldalad tetején jelennek meg a zavaró (és néha ijesztő) kódhalmazok, hanem a háttérben, csendben létrejön egy debug.log nevű fájl a wp-content mappádban. Így a látogatóid semmit nem vesznek észre az „operációból”, te viszont kényelmesen, egy kávé mellett elemezheted a hibaüzeneteket.

Miért használd (és miért ne éles oldalon)?

A debug mód a fejlesztők legjobb barátja, mert segít kiszűrni az elavult (deprecated) kódokat is, mielőtt azok komolyabb bajt okoznának. Segítségével láthatod a PHP hibákat, figyelmeztetéseket és értesítéseket, amik egyébként láthatatlanok maradnának.

Fontos figyelmeztetés: Soha ne hagyd bekapcsolva a képernyőn megjelenő hibaüzeneteket egy éles, látogatók által használt weboldalon! Ezek az üzenetek fontos technikai adatokat árulhatnak el a szerveredről a rosszindulatú támadóknak.

Hibakeresés bővítményekkel

Ha nem szeretnél közvetlenül a kódba nyúlni, léteznek kiváló bővítmények is, amelyek kényelmesebbé teszik a folyamatot:

  • Query Monitor: Ez a legnépszerűbb “svájci bicska” a fejlesztők körében. Nemcsak az adatbázis-lekérdezéseket figyeli, hanem a lassú HTTP kéréseket, a sablonfájlok hierarchiáját és a PHP hibákat is egy jól átlátható kezelőfelületen mutatja meg.
  • Debug Bar: Egy egyszerű, de nagyszerű kiegészítő a WordPress admin sávjához, amely gyors hozzáférést biztosít a legfontosabb debug információkhoz.

Összegzés

A WordPress debug módja nem egy ijesztő programozói fekete mágia, hanem egy hasznos eszköz, ami megspórolja neked az órákig tartó találgatást. Legyen szó egy rakoncátlan sablonról vagy egy hibás bővítményről, a debug.log mindig megmutatja az utat a megoldás felé.