Az üres oldal nem árulja el, hogy egy bővítmény, a sablon vagy a PHP okozza-e a hibát. A wordpress hibakeresés (debug mode) segít kideríteni, hol érdemes keresni a problémát, de rossz beállítás esetén a technikai részletek a látogatók előtt is megjelenhetnek. Ezért a hibákat naplózza, ne a weboldal felületén jelenítse meg.
Nem mindig egyértelmű, mit kell módosítani a wp-config.php fájlban, és hol található a napló. Ebben az útmutatóban lépésről lépésre bemutatjuk a WP_DEBUG és a WP_DEBUG_LOG biztonságos beállítását, a debug.log megkeresését és a bejegyzések értelmezését. Azt is megmutatjuk, mikor érdemes a tárhely PHP-hibanaplóját ellenőrizni, például ha a WordPress még el sem indul. Végül végigvesszük, hogyan kapcsolja ki a hibakeresést, és miért fontos eltávolítani a naplófájlt az éles oldalról. A debug mód nem javítja meg a hibát, de segít megtalálni annak forrását.
Mit jelent a WordPress hibakeresés debug módban, és mikor használja?
A WP_DEBUG a WordPress egyik PHP-állandója. Bekapcsolásakor hibakeresési információk válnak elérhetővé, amelyek segítenek megérteni, mi történik a webhely működése közben. A wordpress hibakeresés (debug mode) hasznos kiindulópont, ha egy hiba után nem világos, hogy a WordPress, a sablon vagy valamelyik bővítmény érintett-e.
A naplóbejegyzéseket kezelje nyomként, ne kész diagnózisként. Egy fájlnév vagy kódsor megmutathatja, hol jelentkezett a probléma, de nem feltétlenül azt, mi váltotta ki. Az üzenet értelmezéséhez vegye figyelembe, milyen művelet előzte meg a hibát, történt-e frissítés, és megismételhető-e a jelenség.
A hibakeresés célja a hiba forrásának módszeres feltárása. A hibakeresés alapjai is ezt a diagnosztikai folyamatot mutatják be. Ez az útmutató a WordPress saját hibakeresési lehetőségére összpontosít. Az adatbázis-kapcsolati hibák és a webkiszolgáló-naplók elemzése külön témakör. A tárhely PHP-hibanaplója akkor lehet hasznos, ha a WordPress még nem jut el addig, hogy saját naplót írjon.
Milyen hibáknál segíthet a WP_DEBUG?
A WP_DEBUG segíthet feltárni a PHP-hibákat, a figyelmeztetéseket és az elavult függvényre utaló üzeneteket. Ezek frissítés után, illetve egy adott oldal, űrlap vagy adminisztrációs művelet használatakor is megjelenhetnek. A naplóban szereplő fájlútvonal utalhat bővítményre, sablonra vagy WordPress-fájlra.
- PHP-hiba: jelezheti, hogy a kód végrehajtása megszakadt.
- Figyelmeztetés: olyan kódrészletre hívhatja fel a figyelmet, amely később problémát okozhat.
- Elavult függvényről szóló üzenet: arra utalhat, hogy egy összetevő régebbi programozási megoldást használ.
Az üzenet önmagában nem bizonyítja, hogy a megnevezett összetevő okozta a hibát. Előfordulhat, hogy egy bővítmény kódja egy másik összetevő hibája miatt fut rosszul. Jegyezze fel, mikor jelent meg az üzenet, milyen művelet előzte meg, és pontosan melyik fájlt nevezi meg.
Mi a különbség a hibakeresési mód és a hibajavítás között?
A WP_DEBUG láthatóvá teszi a hibainformációkat, de nem javítja ki a kódot. A hibakeresés a probléma feltárását szolgálja. A javítás külön lépés, amely az érintett kód vagy beállítás módosítását jelenti. Ezután ellenőrizze, hogy a változtatás megszüntette-e a hibát, és nem okozott-e új működési problémát.
- Diagnózis: rögzítse a hibaüzenetet és a megjelenésének körülményeit.
- Módosítás: a feltárt ok alapján változtasson, lehetőleg tesztkörnyezetben.
- Ellenőrzés: ismételje meg az érintett műveletet, és nézze meg, megszűnt-e a hiba.
Fájlok vagy beállítások módosítása előtt készítsen biztonsági mentést, hogy hiba esetén visszaállíthassa az előző állapotot. Ha rendelkezésre áll tesztkörnyezet, ott ellenőrizze a változtatást, ne közvetlenül a látogatók által használt éles webhelyen.
Hogyan kapcsolja be a WordPress debug módot a wp-config.php fájlban?
A beállításokat a WordPress főkönyvtárában található wp-config.php fájlban kell megadni. Módosítás előtt készítsen biztonsági mentést a fájlról, így egy elgépelés vagy hibás beállítás után visszaállíthatja az eredeti változatot.
- Készítsen mentést. Töltse le a jelenlegi
wp-config.phpfájlt, vagy másolja egy biztonságos helyre. - Nyissa meg a fájlt. A tárhely fájlkezelőjében keresse meg a WordPress telepítési könyvtárát. cPanel felületen a fájlkezelővel megnyithatja és szerkesztheti a fájlt. A cPanel tárhely kezelése során ügyeljen arra, hogy a megfelelő webhely könyvtárában dolgozzon.
- Ellenőrizze a meglévő beállításokat. Keressen rá a
WP_DEBUG,WP_DEBUG_LOGésWP_DEBUG_DISPLAYnevekre. Ha valamelyik már szerepel, az értékét módosítsa, ne adjon hozzá újabb definíciót. - Illessze be a konfigurációt. A sorok a WordPress szerkesztést lezáró megjegyzése elé kerüljenek, amely általában a „That’s all, stop editing!” szöveget tartalmazza. Mentés után töltse be az oldalt, és ellenőrizze a működését.
Melyik WP_DEBUG beállításokat érdemes együtt használni?
A WP_DEBUG bekapcsolja a WordPress hibakeresési módját. A WP_DEBUG_LOG engedélyezi a hibakeresési üzenetek fájlba írását, a WP_DEBUG_DISPLAY pedig azt szabályozza, megjelenjenek-e ezek a weboldalon. Éles oldalon tiltsa le a képernyős megjelenítést. A display_errors PHP-beállítással ezt szintén kikapcsolhatja.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Ez a konfiguráció naplózza a hibákat, de nem jeleníti meg őket a látogatóknak. A Hivatalos WordPress hibakeresési útmutató további részleteket közöl az állandók működéséről és a naplózásról.
Hogyan szerkessze biztonságosan a wp-config.php fájlt?
Mentés előtt ellenőrizze a pontosvesszőket és az idézőjeleket, valamint azt, hogy minden define() sor külön állandót állít be. Ugyanazt az állandót ne határozza meg kétszer, mert ez figyelmeztetést vagy kiszámíthatatlan működést okozhat. Módosítás után próbálja megnyitni a webhelyet és a WordPress adminisztrációs felületét is.
A wordpress hibakeresés (debug mode) során a naplózás biztonságosabb megoldás, mint a részletes PHP-üzenetek közvetlen megjelenítése. Ha a konfigurációs fájl mentése után az oldal hibát jelez, állítsa vissza az elmentett változatot, majd ellenőrizze újra a módosításokat.
Hol találja a debug.log fájlt, és hogyan olvassa a bejegyzéseket?
Ha a naplózást a WP_DEBUG_LOG beállítással engedélyezte, a WordPress alapértelmezés szerint a telepítés wp-content könyvtárában hozza létre a debug.log fájlt. A tárhely fájlkezelőjében nyissa meg a WordPress főkönyvtárát, majd lépjen a wp-content mappába. Keresse meg a fájlt, és töltse le vagy nyissa meg szöveges nézetben. Egyéni naplóútvonal esetén azon a helyen keresse.
Mielőtt átnézi a bejegyzéseket, jegyezze fel, mikor jelentkezett a hiba, és milyen művelet közben. Például rögzítse, ha egy bővítmény frissítése után az adott bővítmény oldalának megnyitásakor üres oldal jelenik meg. Ezután keresse meg az adott időponthoz közeli naplósorokat. A hiba előtti és utáni bejegyzések is fontos összefüggést mutathatnak.
Melyik hibaüzenet lehet a legfontosabb nyom?
Vizsgálja együtt a hiba típusát, az érintett fájl útvonalát és a megadott sorszámot. A fájlnévben megjelenhet egy bővítmény vagy sablon könyvtára, a sorszám pedig megmutatja, hol keletkezett az üzenet az adott fájlban. A hiba időpontja és fájlútvonala együtt szűkíti a vizsgálatot. Ez még nem bizonyítja, hogy az adott összetevő hibás. A figyelmeztetés vagy az elavult függvényre utaló bejegyzés nem feltétlenül állítja le az oldalt.
A PHP-üzenetek naplózásának általános működéséről a PHP hibanaplózás dokumentációja ad tájékoztatást. A WordPress naplója nem azonos a webkiszolgáló naplóival. Ez a rész a debug.log értelmezésére összpontosít, a szervernaplók részletes elemzése külön vizsgálat.
Hogyan válassza külön a tünetet és a lehetséges kiváltó okot?
Hasonlítsa össze a hiba időpontját a közelmúltbeli bővítmény- vagy sablonmódosításokkal, frissítésekkel és beállításváltoztatásokkal. Ha a naplóban egy bővítmény útvonala szerepel, jegyezze fel, hogy a hiba annak frissítése vagy használata után jelentkezett-e. A fájlban megnevezett összetevő érintett lehet, de egy naplóbejegyzés önmagában nem igazolja az ok-okozati kapcsolatot.
A feltételezést ellenőrzött teszttel vizsgálja meg, lehetőleg tesztkörnyezetben, és egyszerre csak egy változtatást végezzen. Így megállapíthatja, hogy a tünet összefügg-e az adott módosítással. A wordpress hibakeresés (debug mode) során a napló nyomait vesse össze a megismételhető viselkedéssel, ne egyetlen sorból vonjon le biztos következtetést.
Hogyan vizsgálja meg a hibát anélkül, hogy adatokat fedne fel?
A napló hasznos műszaki adatokat, útvonalakat és a szerverkörnyezetről árulkodó részleteket is tartalmazhat. Éles weboldalon ezért ne jelenítse meg a PHP-üzeneteket a látogatóknak. A WP_DEBUG_DISPLAY értéke legyen false, a hibákat pedig naplózza fájlba. Ha rendelkezésre áll tesztkörnyezet, ott idézze elő a hibát, így kisebb eséllyel zavarja meg a látogatók webhelyhasználatát.
Kövesse ezt a sorrendet, és a vizsgálat végén állítsa vissza a hibakeresési beállításokat:
- Készítsen biztonsági mentést. A konfiguráció és az érintett fájlok módosítása előtt őrizze meg a jelenlegi állapotot.
- Engedélyezze a naplózást. Állítsa be a hibák fájlba írását, és tiltsa le a képernyős megjelenítést.
- Reprodukálja a hibát. Végezze el azt a műveletet, amelynél a hiba jelentkezik, és jegyezze fel az időpontját.
- Vizsgálja meg a naplót. Keresse meg az adott időponthoz közeli bejegyzést, és rögzítse az üzenetet, a fájl útvonalát, valamint az érintett összetevőt.
- Zárja le a vizsgálatot. Állítsa vissza a hibakeresési beállításokat, és a szükséges információk biztonságos megőrzése után törölje a naplófájlt az éles webhelyről.
Mit tegyen, ha bővítmény vagy sablon neve jelenik meg a naplóban?
Jegyezze fel az összetevő nevét, a teljes hibaüzenetet és a hiba előidézésének körülményeit. Hasonlítsa össze ezeket a közelmúltbeli módosításokkal, de ne tekintse a fájl nevét önmagában bizonyítéknak. Ha rendelkezésre áll tesztkörnyezet, ott ellenőrizze, hogy a jelzett bővítmény vagy sablon kikapcsolása, illetve frissítése megváltoztatja-e a tünetet. Ne töröljön vagy írjon át kódot egyetlen naplósor alapján.
Hogyan védje a hibakeresési információkat?
A diagnózis idején is tartsa kikapcsolva a képernyős hibamegjelenítést. A napló tartalmát ne másolja nyilvános fórumra vagy olyan felületre, ahol bárki hozzáférhet. Ha meg kell osztania egy részletet, előtte távolítsa el belőle a személyes vagy a környezetet azonosító adatokat, például a teljes elérési útvonalakat. A vizsgálat után ellenőrizze, szüksége van-e még a naplóra, és ne hagyja az éles webhelyen tovább gyűlni a bejegyzéseket.
A wordpress hibakeresés (debug mode) lezárásakor ellenőrizze a webhelyet és az adminisztrációs felületet, majd győződjön meg róla, hogy a hibakeresés ki van kapcsolva. A tárhely- és WordPress-beállításokkal kapcsolatos további tájékozódáshoz az aWh tudásbázisa is hasznos kiindulópont.
Hogyan kapcsolja ki a debug módot, és mikor nézze meg a tárhelykörnyezetet?
A hibakeresés lezárásakor ne csak azt ellenőrizze, hogy eltűnt-e a hibaüzenet. Állítsa vissza az ideiglenes beállításokat, távolítsa el a naplófájlt az éles webhelyről, majd tesztelje újra az érintett funkciót. Így a diagnosztikához használt adatok nem maradnak szükségtelenül hozzáférhetők, és azt is ellenőrzi, hogy a webhely visszaállt-e a szokásos működésre.
- Nyissa meg a
wp-config.phpfájlt. Készítsen róla mentést, majd keresse meg a hibakereséshez hozzáadott állandókat. - Kapcsolja ki a hibakeresést. Állítsa a
WP_DEBUGértékétfalse-ra. Ellenőrizze aWP_DEBUG_LOGés aWP_DEBUG_DISPLAYbeállítását is, hogy ne maradjon aktív a naplózás vagy a képernyős megjelenítés. - Mentse a módosítást, majd ellenőrizze az oldalt. Töltse be újra az érintett oldalt és az adminisztrációs felületet. Ismételje meg azt a műveletet is, amely korábban hibát okozott.
- Távolítsa el a már nem szükséges naplót. Ha a diagnózis befejeződött, törölje az éles webhelyről a
debug.logfájlt, hogy annak tartalma ne maradjon ott indokolatlanul.
Milyen ellenőrzéseket végezzen a hibakeresés lezárásakor?
Ellenőrizze, hogy a weboldalon nem jelenik-e meg PHP-hiba vagy technikai figyelmeztetés. Nézze át újra a módosított konfigurációt, különösen az állandók értékét és az esetleges duplikált definíciókat. Ezután tesztelje a korábban hibás funkciót, például a bejelentkezést vagy az érintett oldal betöltését. A WP_DEBUG a diagnózist segíti, de önmagában nem garantálja a hiba megszűnését.
Mikor releváns a WordPress-tárhely és a tudásbázis?
Ha a naplóban inkább a futtatási környezethez kapcsolódó nyomokat talál, különítse el a WordPress beállításait a tárhelyoldali körülményektől. Ilyenkor a tárhelykörnyezet vizsgálata lehet a következő lépés, nem a WordPress-fájlok találomra történő módosítása. A részletes szerveroldali naplóelemzés külön vizsgálatot igényel.
Az aWh WordPress Hosting csomagban előre telepített WordPress érhető el, a WordPress Toolkit Deluxe pedig a WordPress kezelését támogatja. Ezek az üzemeltetést segítő eszközök, nem automatikus hibajavítások. A beállításokkal kapcsolatos további tájékozódáshoz a tudásbázis cikkei gyakorlati kiindulópontot adhatnak. A lezárt wordpress hibakeresés (debug mode) után a tényleges használati folyamatokkal is ellenőrizze az oldal működését.
Őrizze meg a biztonságos működést a hibakeresés után is
A wordpress hibakeresés (debug mode) hasznos vizsgálati eszköz, de csak addig tartsa bekapcsolva, amíg szüksége van a naplóbejegyzésekre. A lezárás után ellenőrizze az oldal működését, és gondolja át, hogyan előzheti meg, hogy egy későbbi frissítés vagy módosítás váratlan fennakadást okozzon. A következetes tesztelés segíthet abban, hogy egy újabb hiba esetén gyorsabban kijelölje a vizsgálat irányát.
A PHP-verzió is része a WordPress üzemeltetési környezetének. A tárhelycsomagokban választható PHP-verziókkal a környezetet a webhely követelményeihez igazíthatja. A beállítás módosításakor jegyezze fel az aktuális verziót és az érintett összetevőket. Így később könnyebb összevetni a működő és a hibát okozó konfigurációt.
A hibakeresés eredményét érdemes röviden dokumentálni. Rögzítse, milyen művelet váltotta ki a hibát, milyen körülmények között jelentkezett, és melyik módosítás után változott meg a működés. Ez a feljegyzés később segíthet elkülöníteni a WordPress beállításainak és a tárhelykörnyezetnek a hatását.
Tekintse meg az aWh WordPress Hosting megoldását, és válasszon az oldal üzemeltetési igényeihez illő környezetet. A gondos hibakeresés és a biztonságos lezárás jó alapot ad a magabiztosabb WordPress-üzemeltetéshez.
Gyakori kérdések a WordPress hibakeresésről
Bekapcsolható a WordPress debug mód adminisztrációs felületről?
A WordPress alapértelmezett adminisztrációs felületén nincs beépített kapcsoló a hibakeresési módhoz. A beállítást jellemzően a wp-config.php fájlban kell elvégezni, megfelelő fájlhozzáféréssel. Egyes bővítmények kínálhatnak saját kezelőfelületet, de ezek külön eszközök, nem a WordPress alapfunkciói. Ha nem tudja szerkeszteni a konfigurációs fájlt, kérjen segítséget a webhely adminisztrátorától.
A WP_DEBUG automatikusan megmutatja, melyik bővítmény okozza a hibát?
Nem feltétlenül. A hibaüzenetben szereplő bővítménynév azt jelezheti, hogy a hiba ott jelentkezett, de nem bizonyítja, hogy az összetevő önmagában felelős. Előfordulhat például, hogy egy bővítmény egy másik bővítmény által átadott hibás adatot dolgoz fel. Jegyezze fel az érintett funkciót és a naplóban látható fájlt, majd tesztkörnyezetben vizsgálja meg, változik-e a tünet az összetevő kikapcsolásakor.
Mit jelent a PHP notice vagy deprecated üzenet a WordPress naplójában?
A notice általában tájékoztató jellegű jelzés a kód működéséről, és önmagában nem feltétlenül állítja le az oldalt. A deprecated üzenet arra figyelmeztet, hogy a kód elavultnak jelölt PHP-függvényt vagy megoldást használ. Keresse meg, melyik fájlhoz kapcsolódik, majd ellenőrizze, hogy a webhely tényleges hibájával egy időben jelenik-e meg. A figyelmeztetés önmagában nem jelenti azt, hogy az oldal hibásan működik.
A WP_DEBUG mód befolyásolhatja a WordPress weboldal teljesítményét?
Igen, a hibakeresés hatással lehet a teljesítményre, különösen, ha sok üzenet keletkezik, és azokat folyamatosan fájlba kell írni. A képernyős megjelenítés a látogatói élményt is ronthatja, ha technikai üzenetek kerülnek az oldalra. Éles webhelyen ezért csak a szükséges vizsgálat idejére használja a hibakeresést, és kapcsolja ki, amikor már nincs rá szüksége.
Használható a WordPress debug mód több webhelyes telepítésnél is?
Igen, de több webhelyes WordPress-telepítésnél vegye figyelembe, hogy a wp-config.php a teljes telepítés konfigurációját kezeli. A benne megadott WP_DEBUG beállítás ezért jellemzően az egész hálózatra vonatkozik, nem csak egy alwebhelyre. A naplóbejegyzések értelmezésekor jegyezze fel, melyik alwebhelyen és milyen műveletnél jelentkezett a hiba. A külön telepítéseknek saját konfigurációs fájljuk van.
Miért nem jön létre a debug.log fájl a WP_DEBUG_LOG bekapcsolása után?
A fájl több okból is hiányozhat. Ellenőrizze, hogy a WP_DEBUG is aktív-e, majd idézzen elő olyan műveletet, amely naplózható üzenetet generál. A naplózás sikertelenségét az is okozhatja, hogy a WordPress nem tud írni a célkönyvtárba, vagy a napló elérési útja egyéni értékre van állítva. Ha a rendszer még a WordPress indulása előtt leáll, a hiba nem feltétlenül kerül ebbe a fájlba.
Ugyanaz a WordPress debug mód és a böngésző fejlesztői konzolja?
Nem. A WordPress hibakeresése elsősorban a szerveroldali PHP-működésről ad információt. A böngésző fejlesztői konzoljával többek között a JavaScript-hibákat, a hálózati kéréseket és az oldal böngészőben történő megjelenítését vizsgálhatja. Ha például egy gomb nem reagál, a konzol adhat nyomot; ha az oldal betöltésekor egy PHP-folyamat hibázik, a WordPress naplója lehet hasznosabb.
2026-10-18