---
title: "WordPress hibanapló"
url: "https://wphu.org/alapok/wordpress-hibanaplo/"
date: "2026-01-24"
modified: "2026-02-25"
author: "Rottenbacher Tamás"
language: "hu_HU"
excerpt: "WordPress hibanapló beállítása, debug mód és PHP error log helye. Gyors WordPress hibakeresés fejlesztőknek és felhasználóknak."
---

# 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.

**Tartalomjegyzék**

## 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](https://wphu.org/alapok/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

- Query Monitor
- Bugmonitor
- Debug Bar
- 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)](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) 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](https://wphu.org/alapok/wordpress-biztonsag/) 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

**Mi az a WordPress hibanapló, és mire jó?**

A [WordPress hibanapló](https://rotisoft.hu/blog/hogyan-keszits-hibanaplot-error-log/) (debug log) a WordPress belső hibáit rögzíti, például plugin- vagy témahibákat, PHP figyelmeztetéseket és runtime hibákat. Segít gyorsan azonosítani a hibák forrását, különösen 500-as hibák vagy váratlan működés esetén.

**Hogyan kapcsolom be a WordPress hibanaplót?**

A wp-config.php fájlban a következő beállításokkal aktiválható a **WordPress hibanapló** (fejlesztéshez javasolt):\
\
`define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );@ini_set( 'display_errors', 0 );`

**Hol található a WordPress hibanapló fájlja?**

Ha a WP_DEBUG_LOG be van kapcsolva, akkor a **WordPress hibanapló** alapértelmezetten a `wp-content/debug.log` fájlba íródik. Ha a fájl nem létezik, a WordPress létrehozza, feltéve hogy a könyvtár írási jogosultsággal rendelkezik.

**Mi a különbség a WordPress hibanapló és a PHP error log között?**

A **WordPress hibanapló** a WordPress működéséből eredő hibákat rögzíti (plugin, téma, core), míg a PHP error log a szerveroldali PHP hibákat (memória limit, PHP-FPM, runtime error) naplózza. Mindkettő fontos a teljes hibakereséshez.

**Milyen PHP beállítások segítenek a hibakeresésben?**

A PHP error log bekapcsolható például így:\
\
`ini_set( 'log_errors', 1 );ini_set( 'error_log', '/path/to/php-error.log' );`\
Ez különösen hasznos, ha a **WordPress hibanapló** nem ad elég információt vagy a hiba szerveroldali jellegű.

**Hogyan lehet fejlesztéskor könnyebben követni a hibákat (haladó beállítások)?**

A WordPress fejlesztői dokumentációja alapján a SCRIPT_DEBUG és a SAVEQUERIES is hasznos:\
\
`define( 'SCRIPT_DEBUG', true );`\
`define( 'SAVEQUERIES', true );`\
A SCRIPT_DEBUG a nem minifikált JS/CSS fájlokat tölti be, a SAVEQUERIES pedig az adatbázis lekérdezéseket naplózza, ami lassú oldalak esetén segít a forrás azonosításában.

**Miért fontos a WP_DEBUG_DISPLAY beállítás?**

Éles környezetben nem ajánlott a hibák megjelenítése a felhasználóknak. A **WordPress hibanapló** célja, hogy a hibák csak a logban jelenjenek meg, ezért a WP_DEBUG_DISPLAY értékét false-ra érdemes állítani, és a display_errors-t is ki kell kapcsolni.

**Hol találom a PHP hibanaplót cPanel, DirectAdmin, Plesk és ISPConfig alatt?**

A PHP hibanapló helye tárhelykezelőnként eltérő, de tipikusan a következő helyeken található:\
\
**cPanel:** /home/USER/logs/DOMAIN.php.error.log vagy /home/USERNAME/public_html/error_log\
**DirectAdmin:** /home/username/domains/yourdomain.com/logs/ vagy a panel Logs menüpontja\
**Plesk:** /var/www/vhosts/yourdomain.com/logs/error_log vagy /var/log/plesk-phpXY-fpm.log\
**ISPConfig:** /var/log/apache2/error.log vagy /var/log/nginx/error.log (domain-specifikus könyvtárakban is lehet)

**Mikor érdemes használni egyedi logolást (error_log)?**

Ha egyedi fejlesztésű funkciókat, AJAX kéréseket vagy webhookokat hibakeresel, akkor a PHP error_log() függvénnyel saját üzeneteket is naplózhatsz. Példa:\
\
`error_log( 'My custom debug message' );`\
Ez segít, ha a hiba nem jelenik meg a WordPress logban vagy a szerver logban, de a kód futását szeretnéd követni.

**Milyen hibanaplós bővítményeket érdemes használni?**

Ha kényelmes, admin felületen elérhető hibakeresést szeretnél, akkor érdemes a következő bővítményeket megemlíteni (említés szintjén): Debug Bar, Query Monitor, Log Deprecated Notices, WP Debugging, Simple History, Error Log Monitor, WP Crontrol, Debug Toolkit. Ezek a bővítmények a **WordPress hibanapló** használatát kiegészítik, és sok esetben gyorsabb diagnosztikát tesznek lehetővé.

## Ö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

WordPress Facebook csoport

Csatlakozzon ~16.000 tagot számláló legnagyobb és fő WordPress-es, magyar nyelvű csoportunkhoz.

[WordPress fejlesztők és felhasználók csoportja → (új ablakban nyílik meg)](https://www.facebook.com/groups/wpcsoport/)

WooCommerce Facebook csoportunk

Várjuk WooCommerce-es magyar nyelvű csoportunkban fejlesztőket és webáruház tulajdonosokat egyaránt.

[WooCommerce fejlesztők és felhasználók csoportja → (új ablakban nyílik meg)](https://www.facebook.com/groups/254329328774362/)

Fórum

WordPress specifikus, saját közösségi terünk. Egy régimódi, hagyományos fórum, ahol szintén lehet segítséget kérni.

[Fórumunk → (új ablakban nyílik meg)](https://tamogatas.wphu.org/)

![](https://secure.gravatar.com/avatar/32e70111c4f82dc85d1d5bb4b7940c43b0f868790fb2ecddb91ac3c9c29c0633?s=150&d=mm&r=pg)

Rottenbacher Tamás

Senior full stack dev, WordPress fejlesztő, honlap és WooCommerce webáruház üzemeltető szakember, vállalkozó (RotiSoft), megszórva online marketing, UX, AI és SEO tapasztalattal és közösségi projektek (TrustedWP, WP MeetUp, WPFórum) embere. [Facebook](https://www.facebook.com/roti.tamas/) | [LinkedIn](https://www.linkedin.com/in/tamasrottenbacher/) | [YouTube](https://www.youtube.com/channel/UCHo6ivNBjNHizNVoGR2h_Fg) | [Instagram](https://www.instagram.com/rotisoft/) | [Weboldal](https://rottenbacher.hu/)