WordPress hibanapló

A WordPress hibanapló (error log) használata alapvető készség mind a kezdő fejlesztők, mind az üzemeltetők számára. Egy hibás plugin, egy inkompatibilis téma, egy PHP verzióváltás vagy egy szerveroldali konfigurációs probléma esetén a WordPress hibanapló jelenti a leggyorsabb és legpontosabb útmutatót a hiba okának feltárásához. A cikk célja, hogy lépésről lépésre bemutassa, hogyan lehet bekapcsolni a WordPress hibanapló funkciót, hol található a PHP hibanapló a legnépszerűbb tárhelykezelőkben, és milyen jó gyakorlatokat érdemes követni a naplók olvasásakor.

WordPress debug funkció bekapcsolása

Mi az a WP_DEBUG és miért kell?

A WordPress hibanapló első lépése a debug mód bekapcsolása. A WP_DEBUG egy olyan állandó, amely a WordPress belső hibajelentését engedélyezi. Fejlesztés során mindenképpen ajánlott bekapcsolni, mert részletes információt ad a hibák forrásáról (plugin, téma, core, PHP warning, notice).

A legfontosabb debug beállítások (wp-config.php)

A WordPress hibanapló valódi értéke akkor jön elő, ha a hibák nem a képernyőre íródnak, hanem naplófájlba. Ehhez a wp-config.php fájlban a következő beállításokat javasolt alkalmazni:

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

Ebben az esetben a WordPress hibanapló a wp-content/debug.log fájlba íródik, miközben a hibák nem jelennek meg a felhasználói felületen.

WP_DEBUG_LOG: hova írja a naplót?

Ha a WP_DEBUG_LOG be van kapcsolva, akkor a WordPress hibanapló alapértelmezetten a wp-content/debug.log fájlba kerül. Ha a fájl nem létezik, a WordPress létrehozza. Fontos, hogy a fájlnak legyen írási joga (pl. 644 vagy 664, attól függően, hogy a szerver hogyan van beállítva).

Miért ne jelenjen meg a hiba az oldalon?

Éles környezetben a hibák megjelenítése biztonsági és felhasználói élmény szempontjából is rossz gyakorlat. A WordPress hibanapló célja, hogy a hibák adminisztratív szinten legyenek láthatók, és ne a látogatók számára.

PHP hibanapló (error log)

PHP error_log beállítás (ini_set)

A WordPress hibanapló mellett gyakran szükség van a PHP általános hibanaplójára is, mert a WordPress log nem minden esetben tartalmazza a szerveroldali PHP hibákat (pl. memória limit, PHP-FPM, runtime error). PHP szinten így lehet bekapcsolni:

ini_set( 'log_errors', 1 );
ini_set( 'error_log', '/path/to/php-error.log' );

WordPress debug log vs. PHP error log – mi a különbség?

A WordPress hibanapló a WordPress belső működéséből eredő hibákat rögzíti (plugin, téma, core, warning, notice), míg a PHP hibanapló a szerveroldali PHP futás során fellépő hibákat rögzíti (memória, PHP-FPM, runtime error, konfigurációs problémák). Mindkettőre szükség lehet a hibakereséshez, de a PHP hibanapló gyakran több információt ad a szerveroldali problémák esetén.

Hol találod a logokat? (tárhelykezelőknél)

cPanel

• Webhely specifikus PHP error log:
  /home/USER/logs/DOMAIN.php.error.log
  /home/USERNAME/public_html/error_log
• cPanel felületen: Metrics → Errors / Raw Access Logs

DirectAdmin

• Domain log könyvtár: /home/username/domains/yourdomain.com/logs/
• Panelen: Site Summary → Statistics → Logs → Error Log
• Apache/nginx logok (ha nincs külön PHP log)

Plesk

• Domain log: /var/www/vhosts/yourdomain.com/logs/error_log
• PHP-FPM log: /var/log/plesk-phpXY-fpm.log
• Plesk felület: Domain → Logs → PHP Errors filter

ISPConfig

• Általában webserver logok (Apache/nginx) alatt:
  /var/log/apache2/error.log
  /var/log/nginx/error.log
• Domain-specifikus logok (szerver beállítás függő)

A leggyakoribb hibák és mit jelentenek

500 Internal Server Error

Tipikus okok: memória limit, plugin, PHP verzió, .htaccess. Ilyenkor a PHP hibanapló és a WordPress hibanapló is elsődleges forrás.

Fatal error / uncaught error

Pl. class not found, undefined function. A hiba sor alapján könnyen beazonosítható a hibás plugin vagy téma.

Deprecated warning / notice

A PHP verzióváltáskor gyakori. Fejlesztéskor fontos, éles oldalon általában el kell kerülni a megjelenítését.

Database connection errors

Az adatbázis elérés hibái (hibás host, jelszó, adatbázis név) tipikusan a wp-config.php beállításokban keresendők.

Hibanapló olvasási és szűrési tippek

• A legutóbbi bejegyzések megtekintése: tail -f debug.log vagy error_log
• Kulcsszavak: Fatal, Warning, Deprecated, Stack trace
• A hiba forrásának azonosítása: plugin/sablon fájlnevek, sorok, függvények alapján
• Ha több plugin is érintett: próbálj meg ideiglenesen letiltani pluginokat, és figyeld a log változását

Hibanaplós bővítmények

• Debug Bar
• Query Monitor
• Log Deprecated Notices
• WP Debugging
• Simple History
• Error Log Monitor
• Debug Toolkit

Debugging fejlesztőknek

A WordPress hivatalos debugging dokumentációja (új ablakban nyílik meg) alapján a WordPress hibanapló használata mellett több olyan fejlesztői eszköz is rendelkezésre áll, amelyek a hibakeresést hatékonyabbá teszik. Ezek közül az egyik a SCRIPT_DEBUG konstans, amely fejlesztői környezetben a minifikált (összevont) JavaScript és CSS fájlok helyett a nem minősített verziókat tölti be. Ez különösen hasznos, ha front-end hibákat vagy stílusproblémákat kell gyorsan azonosítani, mert könnyebb így követni a konkrét fájlok és sorok szerinti hibákat.

define( 'SCRIPT_DEBUG', true );

A másik fontos eszköz a SAVEQUERIES, amely a futó adatbázis-lekérdezéseket gyűjti és tárolja egy tömbben. Lassú oldalbetöltés vagy váratlan adatbázis-terhelés esetén ez a funkció lehetővé teszi a lekérdezések elemzését, és segít megtalálni a teljesítményproblémák forrását.

define( 'SAVEQUERIES', true );

A WordPress dokumentáció kiemeli, hogy a WP_DEBUG bekapcsolása nemcsak hibákat, hanem elavult (deprecated) funkciók használatáról szóló figyelmeztetéseket is naplózza. Ezek a figyelmeztetések fontos iránymutatást adnak arra, hogy melyik kód rész fog a jövőben megszűnni, így előre lehet tervezni a kompatibilitási frissítéseket. Ugyancsak hasznos a PHP beépített error_log() függvényének alkalmazása, amely nem csak hibák, hanem egyedi üzenetek vagy változók naplózására is alkalmas. Ezzel például AJAX kérések, webhookok vagy egyedi fejlesztésű funkciók hibáinak követése válik egyszerűbbé.

error_log( 'My custom debug message' );

Biztonsági és üzemeltetési jó gyakorlatok

Éles oldalon ne jelenjen meg a hiba a felhasználónak

A WP_DEBUG_DISPLAY false és a display_errors off biztosítja, hogy a hiba csak a logban jelenjen meg.

Logok tárolása és hozzáférés

A debug.log és a PHP error log ne legyenek publikusak. A jogosultságok és az esetleges .htaccess védelem fontos.

Log forgatás (log rotation)

A logok mérete gyorsan nőhet, ezért érdemes logrotate vagy hasonló megoldást alkalmazni a szerveren.

Gyakori kérdések és válaszok a hibanaplóról

Összegzés

A WordPress hibanapló használata a leggyorsabb módja annak, hogy egy weboldalon fellépő hibákat észleljünk és pontosan azonosítsuk a forrásukat. Ha egy plugin vagy téma nem kompatibilis, ha a PHP verzió vagy a szerverkonfiguráció okoz problémát, vagy ha egy 500-as hibával találkozunk, a WordPress hibanapló és a PHP hibanapló együttesen adják meg a szükséges információt. A WordPress saját debug rendszerét érdemes elsőként bekapcsolni, mert a WP_DEBUG, WP_DEBUG_LOG és WP_DEBUG_DISPLAY beállítások segítségével a hibák fájlba írása biztosítható anélkül, hogy a látogatók számára láthatóvá válnának.

A hibaelhárítás során fontos, hogy ne csak a WordPress logot nézzük, hanem a PHP hibanaplót is, mert bizonyos hibák (például memória limit túllépés, PHP-FPM problémák vagy runtime errorok) csak ott jelennek meg. A PHP hibanapló helye tárhelykezelőnként eltérő, ezért az üzemeltetőknek és fejlesztőknek érdemes ismerniük, hol található a log fájl cPanel, DirectAdmin, Plesk vagy ISPConfig környezetben. Ezek a helyek gyakran a webhely log könyvtárában vagy a szerver általános log könyvtáraiban vannak, és a panelen keresztül is elérhetők lehetnek.

A hibanaplók olvasása során hasznos, ha a legutóbbi bejegyzéseket a megfelelő eszközökkel követjük, és a kulcsszavakra, például Fatal, Warning vagy Deprecated figyelünk. A hiba forrását gyakran a fájlnevek, sorok és függvények alapján lehet beazonosítani, és ha több plugin érintett, akkor a hibakereséshez a pluginok ideiglenes letiltása is segíthet. A logok olvasása és értelmezése külön készség, de a WordPress hibanapló használatával a hibák felderítése sokkal gyorsabb és megbízhatóbb, mint pusztán a hibajelzések vagy a böngészőben megjelenő üzenetek alapján.

A biztonsági és üzemeltetési gyakorlatok közé tartozik, hogy éles környezetben a hibák ne jelenjenek meg a felhasználók számára, és a logok ne legyenek nyilvánosan elérhetők. A debug.log és a PHP error log jogosultságait megfelelően kell kezelni, és szükség esetén .htaccess vagy más szerveroldali megoldással védeni. Emellett a logok mérete gyorsan növekedhet, ezért érdemes log forgatást alkalmazni, hogy a naplófájlok ne foglaljanak el túl sok tárhelyet. Összességében a WordPress hibanapló bevezetése és a PHP logok rendszeres ellenőrzése a weboldal stabilitásának és a hibák gyors javításának egyik alapja.

Segítség kellene? Közösségeink