Hol van a WordPress hibanapló, és hogyan olvasd? (WP_DEBUG útmutató)

Frissítve: 2026. szeptember · Írta: Busai Gábor, 15+ év WordPress-tapasztalat

A legtöbb WordPress-hibaelhárítás így néz ki: kikapcsolunk egy bővítményt, megnézzük. Nem jó. Kikapcsolunk egy másikat, megnézzük. Nem jó. Fél óra múlva már azt sem tudjuk, mit kapcsoltunk ki.

Pedig a WordPress pontosan megmondja, mi a baj – csak alapból nem írja ki. Egyetlen fájlba írja, amit be kell kapcsolni. Ha egyszer megtanulod elolvasni ezt a naplót, a hibakeresés találgatásból két perces olvasássá válik.

Miért éri meg megtanulni

Három okból:

• Megmondja a hibás fájlt és a sort. Nem azt, hogy „valami baj van", hanem azt, hogy a Valami bővítmény class-main.php fájljának 218. sora.
• Akkor is működik, amikor semmi más. Fehér képernyőnél, kritikus hibánál, amikor be sem tudsz lépni az adminba.
• Megelőzésre is jó. A napló tele van figyelmeztetésekkel olyan dolgokról, amik ma még működnek, de a következő PHP-verzióban el fognak törni.

Hogyan kapcsold be a hibanaplózást

Szükséged lesz hozzáférésre a fájlokhoz: FTP/SFTP (FileZilla), a tárhely fájlkezelője, vagy SSH. Az adminban lévő fájlszerkesztő is jó lenne – de pont akkor nem éred el, amikor a legnagyobb szükség lenne rá.

Nyisd meg a WordPress gyökérkönyvtárában lévő wp-config.php fájlt. Keresd meg ezt a sort:

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

Magyar telepítésnél: /* Ennyi, kész is vagy! Jó blogolást! */

Ez fölé – és nem alá, mert ott már késő – illeszd be:

// Hibanapló bekapcsolása
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ha a fájlban már szerepel egy define( 'WP_DEBUG', false ); sor, azt írd át – ne írj be másodikat, mert a PHP az elsőt veszi figyelembe, a másodikra pedig figyelmeztetést dob.

Mentsd a fájlt, majd töltsd be újra azt az oldalt, ahol a hiba jelentkezik. A naplófájl ekkor jön létre.

Mit csinál ez a négy sor?

Naplózás egy biztonságosabb helyre

A /wp-content/debug.log fájl alapból böngészőből is letölthető, ha valaki kitalálja a címét – márpedig ez az első dolog, amit egy automata szkenner megpróbál. Ha nem csak néhány percre kapcsolod be a naplózást, tedd a fájlt a webgyökér alá:

define( 'WP_DEBUG_LOG', '/home/felhasznalo/logs/wp-debug.log' );

A WP_DEBUG_LOG ugyanis nem csak true/false lehet, hanem egy elérési út is. Ha a tárhelyen nem tudsz a webgyökér fölé írni, akkor legalább tiltsd le a fájl elérését a wp-content mappa .htaccess fájljában:

<Files debug.log>
  Require all denied
</Files>

Hol találod a naplót?

Három helyen érdemes keresni, ebben a sorrendben:

1. /wp-content/debug.log – a WordPress saját naplója, amit az előbb kapcsoltál be.
2. A szerver PHP-naplója. cPanel-es tárhelyen általában error_log néven a public_html-ben vagy az adott könyvtárban, ahol a hiba történt. Ez akkor is létezik, ha a WP_DEBUG ki van kapcsolva – érdemes ránézni legelőször.
3. A tárhely vezérlőpultjának naplómenüje. A legtöbb magyar szolgáltatónál (RackForest, DotRoll és a cPanel-es szolgáltatók) van egy „Hibanaplók" vagy „Errors" menüpont, ami kiírja az utolsó néhány száz sort. Ez a leggyorsabb út, ha még FTP-t sem akarsz indítani.

Ha a debug.log nem jön létre, annak általában az az oka, hogy a wp-content mappa nem írható. Ilyenkor a szerver saját naplója marad.

Hogyan olvasd el a naplót

Nyisd meg a fájlt, és görgess a legaljára. A napló időrendben nő, tehát a legfrissebb – vagyis az, ami az imént történt – legalul van. Egy tipikus sor így néz ki:

[24-Sep-2026 07:12:33 UTC] PHP Fatal error:  Uncaught Error:
Call to undefined function wc_get_product() in
/home/felhasznalo/public_html/wp-content/plugins/pelda-bovitmeny/render.php:141
Stack trace:
#0 /home/.../wp-includes/class-wp-hook.php(324): pelda_render_termek('')
#1 /home/.../wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#2 {main}
  thrown in /home/.../wp-content/plugins/pelda-bovitmeny/render.php on line 141

Négy dolgot olvass ki belőle:

Az útvonalból azonnal látszik, hol keresd

• /wp-content/plugins/valami/ → bővítmény. Kapcsold ki, és nézd meg, elmúlik-e.
• /wp-content/themes/valami/ → a sablon, vagy egy kód, amit a functions.php-be tettél.
• /wp-includes/ vagy /wp-admin/ → core fájl. Ez ritkán maga a WordPress hibája; jellemzően PHP-verzió eltérés, sérült fájl, vagy egy bővítmény hívott meg rosszul valamit. A stack trace ilyenkor elárulja az igazi kiindulópontot.
• /mu-plugins/ → „must-use" bővítmény. Ezek nem jelennek meg a normál bővítménylistában, és nem kapcsolhatók ki az adminból. Ha ide mutat a hiba, és nem emlékszel rá, hogy tettél volna oda bármit, az feltörésre is utalhat.

A hibaszintek: mi számít, mi nem

A napló első olvasásra ijesztő, mert tele van piros szavakkal. A többsége lényegtelen. Íme a sorrend, amiben érdemes foglalkozni velük:

Fatal error – ezzel kezdd

Ez állítja meg az oldalt. Ha „kritikus hiba" vagy fehér képernyő van, itt a válasz. Ha egyetlen sort olvasol el a naplóból, ez legyen az.

Tipikus üzenetek és jelentésük:

Warning – nézd meg, ha valami furcsán viselkedik

Nem állítja meg az oldalt, de valami nem úgy megy, ahogy kellene. Ha az oldal működik, de egy funkció nem, itt keresd.

Notice és Deprecated – a zaj

A Deprecated azt jelenti: „ez még működik, de egy jövőbeli PHP-verzióban el fog törni". Élő oldalon ezekből több ezer sor is keletkezhet naponta, főleg régebbi bővítményeknél. Most nem okoznak bajt – de ezek fognak fatal errorrá válni a következő PHP-frissítéskor. Érdemes felírni, melyik bővítmény termeli őket.

Ha a naplót elárasztják és nem látod tőlük a lényeget, ideiglenesen szűkítheted:

@ini_set( 'error_reporting', E_ALL & ~E_DEPRECATED & ~E_NOTICE );

Négy valós példa, megfejtve

1. „Csütörtök óta nem megy a kapcsolati űrlap"

PHP Warning:  mail(): Failed to connect to mailserver at "localhost" port 25
in /wp-includes/pluggable.php on line 500

Fordítás: a szerver nem tud levelet küldeni. Nem a bővítmény hibás – a tárhely nem enged PHP mail() hívást. Megoldás: SMTP-beállítás. Erről bővebben: Miért nem kapom meg a levelet?

2. „Frissítettem, és eltűnt a webshop"

PHP Fatal error:  Uncaught Error: Call to undefined method
WC_Product::get_valami() in /wp-content/plugins/egyedi-bovitmeny/class-ar.php:88

Fordítás: egy egyedi bővítmény olyan WooCommerce-funkciót hív, ami az új verzióból kikerült. A WooCommerce nem hibás, az egyedi bővítmény elavult. Gyorsjavítás: a bővítmény kikapcsolása, utána fejlesztői javítás.

3. „Néha lassú, néha hibát dob"

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /wp-includes/wp-db.php on line 2056

Fordítás: elfogyott a 256 MB memória egy adatbázis-lekérdezés közben. Figyeld meg: az utolsó foglalás mindössze 20 kB volt – vagyis nem ez az egy művelet a bűnös, hanem valami előtte már felzabálta a memóriát. Itt a memóriakorlát emelése csak tüneti kezelés.

4. Ez a sor rossz hír

PHP Warning:  file_get_contents(https://xn--e1aybc.xyz/l.txt): failed to open stream
in /wp-content/uploads/2024/03/wp-cache.php on line 1

Fordítás: egy PHP-fájl fut az uploads mappából, és egy ismeretlen külső szerverről próbál letölteni valamit. Az uploads mappában sosem szabadna PHP-fájlnak lennie – ez feltörés. Ilyenkor a napló már nem hibakeresés, hanem bizonyíték: ne törölj, ne írj felül semmit, mert az eltünteti a nyomokat.

A stack trace: melyik sor az érdekes?

A stack trace az az útvonal, ahogy a kód a hibáig eljutott. Alulról felfelé épül, tehát:

• a #0 sor a legutolsó lépés a hiba előtt – ez a leginformatívabb,
• a legmagasabb számú sor a kiindulópont (általában valami WordPress core fájl),
• a köztes class-wp-hook.php sorok csak azt mutatják, hogy egy hookon keresztül hívódott meg a kód – ezeket nyugodtan átugorhatod.

A trükk: keresd meg a stack trace-ben a legelső olyan sort, ami nem a wp-includes vagy wp-admin mappából jön. Az a te kódod vagy a bővítményed – ott kezdődött a baj.

Hasznos wp-config kapcsolók, amiket kevesen ismernek

Ha vizuálisabb eszközt szeretnél, a Query Monitor bővítmény ugyanezt az információt mutatja meg az admin sávban, lekérdezésekkel és hook-okkal együtt. Élő oldalon viszont ne hagyd bekapcsolva – lassít, és többet mutat, mint amennyit szabadna.

Kapcsold ki, ha végeztél

Ez nem opcionális lépés. Két okból:

1. Biztonság. A debug.log tele van szerverútvonalakkal, néha felhasználónevekkel és lekérdezésrészletekkel.
2. Lemez és sebesség. Láttam már 4 GB-os debug.log fájlt egy webtárhelyen. A tárhely megtelt, az oldal leállt – a hibakeresés okozta a következő hibát.

Végezetül állítsd vissza:

define( 'WP_DEBUG', false );

És töröld a debug.log fájlt, ne csak ürítsd ki. Ha rendszeresen szükséged van rá, állíts be logrotációt, vagy tedd a webgyökér fölé, ahogy fentebb írtam.

Gyakori kérdések

Kapcsolódó olvasnivaló: „Kritikus hiba történt a webhelyén" – mit jelent, és hogyan javítsd · Havi WordPress karbantartás