Tudásbázis

Röviden: hol keresd a hibákat?

• Mi az az error log, és miért fontos?
• Milyen logtípusokkal találkozol a tárhelyeden?
  • Apache / Nginx error log (webszerver log)
  • PHP error log
  • Weboldal / keretrendszer (CMS) saját debug logja
• Hol találod meg a logokat cPanelen?
  • Apache / Nginx hibanapló – Hibák (Errors) menü
  • PHP error log – ha be van kapcsolva a PHP-FPM
  • PHP error log – ha nincs PHP-FPM
• WordPress debug log (debug.log) bekapcsolása
• Joomla és egyéb alkalmazások logjai
• Hogyan olvass és értelmezz egy logsort?
• Tipikus (és kevésbé tipikus, de fontos) hibák és mit tehetsz ellenük?
• Mikor és mit küldj el nekünk a logokból?
• Biztonság és teljesítmény – mire figyelj logolás közben?
• GYIK – Error logokkal kapcsolatos gyakori kérdések

Röviden: hol keresd a hibákat?

Ha a weboldalad hibát dob (HTTP 500, fehér képernyő, váratlan hiba), az első lépés mindig az error logok átnézése. Nálunk három fő logforrásod van:

1. Apache / Nginx hibanapló (error log)
   Teljes loghoz csak rendszergazdáink férnek hozzá.
   Menedzselt tárhely esetén te is látsz belőle kivonatot a cPanelen:
   • Hibák / Errors menü – itt a rendszer kiszűri a saját tárhelyedhez tartozó hibanapló sorokat.
2. PHP error log
   • Ha be van kapcsolva a PHP-FPM az adott domainre: /home/FELHASZNÁLÓNÉV/logs mappában találod a PHP hibalogokat.
   • Ha nincs PHP-FPM, akkor a log:
     • a php.ini fájlban megadott error_log útvonalon, vagy
     • azon az útvonalon, amit maga a CMS (WordPress, Joomla stb.) beállít magának.
3. Weboldal / CMS debug log (pl. WordPress debug.log)
   • Ezeket külön kell bekapcsolni, és tipikusan a weboldalad könyvtárában jönnek létre, pl.:
     • WordPress: wp-content/debug.log
     • Joomla: a Joomla konfigurációban megadott log_path mappában.

Ha ezek alapján sem egyértelmű a hiba oka, másold ki a legfrissebb logrészletet és írj nekünk ticketet:
https://ugyfeladmin.tarhely.eu/submitticket.php

Mi az az error log, és miért fontos?

Az error log (hibanapló) a webkiszolgáló és a PHP által írt naplófájl, amelyben hibák, figyelmeztetések és sokszor a „láthatatlan” problémák is megjelennek.

Miért nélkülözhetetlen?

• Megmutatja, mi történt pontosan, amikor a hiba jelentkezett.
• Nem csak azt látod, hogy „HTTP 500 Internal Server Error”, hanem azt is, hogy például:
  • elfogyott a memória (Allowed memory size exhausted),
  • lejárt a futási idő (Maximum execution time exceeded),
  • hiányzik egy fájl (No such file or directory),
  • adatbázis hiba van (Access denied for user, Unknown database).
• Segít eldönteni, hogy:
  • te magad is meg tudod oldani (pl. bővítmény kikapcsolás, memory_limit emelés), vagy
  • inkább ügyfélszolgálatunk segítségére van szükség.

Milyen logtípusokkal találkozol a tárhelyeden?

Apache / Nginx error log (webszerver log)

A háttérben az Apache / Nginx hibanaplóba kerülnek a webszerver hibái.

Nálunk:

• a teljes Apache / Nginx error loghoz közvetlenül nem férsz hozzá (ez root szintű jogosultság),
• menedzselt tárhely esetén a cPanelen, a Hibák (Errors) menüpontban láthatod azokat a hibasorokat, amelyek a saját tárhelyedhez tartoznak.

Ez a felület nagyon hasznos minden olyan esetben, amikor:

• HTTP 500 vagy 503 hibát kapsz,
• valamilyen Apache modul panaszkodik (pl. mod_rewrite),
• .htaccess hibák vannak (pl. „RewriteRule: bad flag delimiters”).

PHP error log

A PHP error log kifejezetten a PHP futás közben keletkező hibáit rögzíti.

Nálunk ennek a helye attól függ, hogy a domainen PHP-FPM be van-e kapcsolva.

• Ha PHP-FPM be van kapcsolva az adott domainre:
  • A státuszt a cPanelen a MultiPHP Manager menüpontban látod.
  • Ilyenkor a PHP hibák a tárhelyeden található /home/FELHASZNÁLÓNÉV/logs mappába kerülnek (több fájl is lehet, domainenként, dátum szerint).
• Ha PHP-FPM nincs bekapcsolva:
  • a PHP hibaüzenetek elsősorban oda íródnak, amit a php.ini vagy a CMS konfigurációja error_log-nak beállít,
  • vagy ha a CMS más logolási megoldást használ, akkor annak a saját log mappájába.

Ha a logolás technikai beállításában bizonytalan vagy, érdemes fejlesztővel egyeztetned, vagy kérdezz rá nálunk ticketben – itt elsősorban a logok olvasására és értelmezésére koncentrálunk.

Weboldal / keretrendszer (CMS) saját debug logja

A legtöbb népszerű rendszernek (WordPress, Joomla, Laravel, stb.) van saját debug logja.

• Ezeket jellemzően külön kell bekapcsolni,
• és általában a weboldal könyvtárán belül jönnek létre.

Példák:

• WordPress: wp-content/debug.log
• Joomla: a konfigurációban (configuration.php / admin felület) megadott log_path mappában lévő fájlok
• Más keretrendszerek: pl. Laravel: storage/logs/laravel.log

Ezekben a logokban gyakran részletesebb stack trace is van (melyik függvény mit hívott, milyen sorrendben), ami fejlesztésnél vagy összetettebb hibáknál nagyon hasznos.

Hol találod meg a logokat cPanelen?

Apache / Nginx hibanapló – Hibák (Errors) menü

1. Lépj be a cPanel felületre.
2. Keresd meg a Metrics / Mutató blokkot.
3. Kattints a Hibák vagy Errors menüpontra.

Itt látni fogod a legutóbbi hibasorokat, például:

• HTTP 500 hibákhoz tartozó részletes üzeneteket,
• .htaccess hibákat,
• egyes PHP hibákat, ha a webszerver is naplózza őket.

Fontos:
Ez a nézet egy szűrt kivonat, ami csak a te tárhelyedhez tartozó bejegyzéseket mutatja, a teljes szerver-szintű loghoz csak rendszergazdáink férnek hozzá.

PHP error log – ha be van kapcsolva a PHP-FPM

1. Ellenőrizd a MultiPHP Manager menüpontban, hogy a domainnél be van-e kapcsolva a PHP-FPM.
2. Nyisd meg a File Manager / Fájlkezelő menüt.
3. Navigálj a következő könyvtárba:
   • /home/FELHASZNÁLÓNÉV/logs

Itt általában olyan fájlokat találsz, amelyek nevében benne van:

• a domain neve,
• és/vagy a php szó,
• valamint dátum/idő jelölés.

A legfrissebb módosítási idővel rendelkező fájlt érdemes megnyitni.

PHP error log – ha nincs PHP-FPM

Ha a domainen nincs PHP-FPM:

• a PHP hibaüzenetek elsősorban oda íródnak, amit a php.ini vagy a CMS konfigurációja error_log-nak beállít,
• vagy ha a CMS más logolási megoldást használ, akkor annak a saját log mappájába.

Ha nem találod a logot, sokszor a CMS dokumentációja jelzi, hova ír, vagy kérdezhetsz rá nálunk ticketben, és ellenőrizzük a beállításokat.

WordPress debug log (debug.log) bekapcsolása

A WordPress saját, részletes hibalogot tud írni a wp-content/debug.log fájlba.

1. lépés: wp-config.php szerkesztése

1. Nyisd meg a File Manager / Fájlkezelő menüt cPanelen.
2. Navigálj a WordPress telepítési könyvtárába (pl. public_html).
3. Keresd meg a wp-config.php fájlt.
4. Kattints rá jobb gombbal → Edit / Szerkesztés.

A következő sorokat add hozzá (vagy módosítsd, ha már léteznek):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Általában a /* That's all, stop editing! Happy publishing. */ sor előtt szokás elhelyezni őket.

2. lépés: debug.log megkeresése

1. Lépj a wp-content mappába.
2. Keresd a debug.log fájlt.

Ebben fogod látni:

• a PHP hibákat, amelyeket a WordPress érzékel,
• a plugin / sablon hibákat,
• részletes stack trace-eket.

Fontos:
Ha végeztél a hibakereséssel, kapcsold ki a debug módot (állítsd a WP_DEBUG-ot false-ra), mert:

• a log gyorsan nőhet,
• érzékeny információk is bekerülhetnek.

Joomla és egyéb alkalmazások logjai

Joomla debug és log mappa

Joomla esetén több helyen is találhatsz logot:

1. Globális konfiguráció → Rendszer
   • Itt kapcsolható a Debug mód.
2. Konfiguráció → Szerver / System részben találod a Log path beállítást.
   • Ez mutatja, melyik könyvtárba írja a Joomla a logokat (pl. logs vagy administrator/logs).

A logfájlokban tipikusan:

• bővítmény / modul hibák,
• adatbázis hibák,
• PHP figyelmeztetések jelennek meg.

Egyéb keretrendszerek (Laravel, Symfony, saját fejlesztés)

• Laravel: storage/logs/laravel.log
• Symfony: var/log mappa
• Saját fejlesztésnél: a fejlesztő által megadott log mappa (erről a fejlesztőtől tudsz pontos információt kérni).

Hogyan olvass és értelmezz egy logsort?

Vegyünk egy tipikus PHP hibát:

[2025-11-25 12:34:56] PHP Fatal error:  Uncaught Error: Call to undefined function my_missing_function() in /home/felhasznalo/public_html/wp-content/themes/sajat-tema/functions.php:123

Mit jelentenek az elemek?

• [2025-11-25 12:34:56] – időpont, mikor történt a hiba
• PHP Fatal error – hibaszint (súlyos, a script futása leáll)
• Uncaught Error: Call to undefined function ... – hibaüzenet
• …functions.php:123 – melyik fájlban, hányadik sorban történt a hiba

Általános tipp:

• mindig a legfrissebb sorokat nézd (log végén),
• keresd a Fatal error, Parse error, Warning, Notice kifejezéseket,
• figyeld a fájlt és sorszámot, ez segít beazonosítani a hibás kódot vagy bővítményt.

Tipikus hibák és mit tehetsz ellenük?

1. memory_limit hiba

Példa:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate ...)

Mit jelent?
A PHP elérte a beállított memória-limitet (pl. 128M).

Mit tehetsz?

• Emeld a memory_limit értékét (pl. 256M vagy 512M – a csomagod keretein belül).
• Ha így is kifut, nézd át, melyik bővítmény / folyamat használ sok memóriát (log alapján sokszor látszik).
• Ha a szükséges érték irreálisan magas lenne, vagy nem egyértelmű az ok, írj nekünk ticketet, és csatold a logrészletet.

2. max_execution_time hiba

Példa:

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /home/...

Mit jelent?
A script futási ideje meghaladta a max_execution_time limitet (pl. 30 másodperc).

Mit tehetsz?

• Növeld a futási idő limitet (ésszerű kereteken belül, pl. 60–120).
• Ha nagy importot / migrációt futtatsz, ez természetes is lehet.
• Ha egy sima oldalbetöltésnél lép fel, valószínűleg egy bővítmény / lassú SQL lekérdezés okozza – ilyenkor érdemes optimalizálni, vagy fejlesztővel / ügyfélszolgálatunkkal egyeztetni.

3. include/require hibák (hiányzó fájl)

Példa:

PHP Warning:  include(/home/.../valami.php): failed to open stream: No such file or directory in /home/.../index.php on line 45

Mit jelent?
A script próbál betölteni egy fájlt, ami nem létezik vagy nem érhető el.

Mit tehetsz?

• Ellenőrizd, hogy a hivatkozott fájl tényleg ott van-e.
• Ha bővítmény / sablon frissítés után jött elő, lehet, hogy a frissítés megszakadt, töltsd fel újra.
• Bizonytalan esetben másold ki a logrészletet és írj nekünk ticketet.

4. Jogosultsági hibák – „Permission denied”

Példa:

PHP Warning:  file_put_contents(...): failed to open stream: Permission denied in /home/...

Mit jelent?
A PHP nem tud írni/olvasni egy fájlt vagy mappát a jogosultságok miatt.

Mit tehetsz?

• Fájlkezelőben ellenőrizd a jogosultságokat:
  • fájloknál jellemzően 0644,
  • könyvtáraknál 0755 javasolt.
• Ha sok fájl / mappa érintett, vagy nem vagy biztos abban, mit lehet átírni, kérj segítséget ügyfélszolgálatunktól.

5. Adatbázis hibák

Példák:

PHP Warning:  mysqli_connect(): (HY000/1045): Access denied for user 'dbuser'@'localhost' (using password: YES)

PDOException: SQLSTATE[HY000] [1049] Unknown database 'adatbazisnev'

Mit jelent?

• Rossz adatbázis felhasználónév / jelszó,
• nem létezik az adatbázis,
• a felhasználónak nincs jogosultsága az adatbázisra.

Mit tehetsz?

• Ellenőrizd a weboldalad konfigurációs fájlját (WordPress: wp-config.php, Joomla: configuration.php stb.).
• Nézd meg, hogy a cPanel → MySQL Databases menüben:
  • létezik-e az adatbázis,
  • hozzá van-e rendelve a megfelelő user,
  • helyes-e a jelszó.
• Ha nem egyértelmű, küldd el nekünk a releváns logrészletet (jelszó nélkül).

6. Session hiba – session_start(): Failed to read session data / session.save_path

Példa:

PHP Warning:  session_start(): Failed to read session data: files (path: /var/cpanel/php/sessions/ea-phpXX) in /home/...

Mit jelent?
A PHP nem tudja használni a session tárolót (pl. nem írható a session.save_path, vagy sérült session fájlok vannak).

Mit tehetsz?

• Ha saját session útvonalat használsz, ellenőrizd, hogy a mappa létezik-e és írható-e.
• Ha rendszer alapértelmezett útvonalat látsz (pl. /var/cpanel/php/sessions/...), és folyamatosan ilyen hiba jelenik meg, másold ki a logrészletet és jelezd nekünk ticketben – ezt rendszerszinten tudjuk ellenőrizni.

7. Header hiba – „Cannot modify header information”

Példa:

PHP Warning:  Cannot modify header information - headers already sent by (output started at /home/.../file.php:10) in /home/.../file.php on line 50

Mit jelent?
A PHP már küldött kimenetet a böngészőnek (pl. szóköz, BOM, echo), és ezután próbál HTTP fejléceket küldeni (pl. header(), setcookie()).

Mit tehetsz?

• A hibaüzenetben megadott „output started at” fájl / sorszám környékén keresd a felesleges kiírást:
  • üres sor a <?php előtt,
  • HTML / echo,
  • BOM (rejtett karakter a fájl elején).
• Ha a hiba plugin / sablon fájlban van, érdemes fejlesztővel egyeztetni vagy a bővítményt másikra cserélni.

8. cURL / külső API hibák

Példák:

cURL error 28: Connection timed out after 5000 milliseconds
cURL error 60: SSL certificate problem: certificate has expired

Mit jelent?

• A weboldal cURL-lel próbál csatlakozni egy külső szolgáltatáshoz (API, fizetési rendszer, külső kép/forrás), de:
  • nem válaszol időben,
  • tanúsítványhiba van,
  • tűzfal / hálózati probléma akadályozza.

Mit tehetsz?

• Ellenőrizd, hogy a hivatkozott külső szolgáltatás elérhető-e böngészőből.
• Ha saját fejlesztésű integrációról van szó, a fejlesztővel nézessétek át a timeout értékeket, hívott URL-t, tanúsítványt.
• Ha biztos vagy benne, hogy a külső szolgáltatás rendben van, de cURL hibát kapsz, csatold a logrészletet a tickethez, mi oldalunkról is megvizsgáljuk.

9. mod_security / WAF által blokkolt kérések

Példák (Apache / Errors kivonatban):

ModSecurity: Access denied with code 406 (phase 2). Pattern match "(?i:(select\s+.+from))" at ARGS:search.

Mit jelent?
A webszerver WAF / mod_security szabályrendszere gyanúsnak ítélte a kérést (SQL injection gyanú, XSS, stb.), és blokkolta.

Mit tehetsz?

• Ha egyértelműen valós látogatói / admin műveletet blokkol (pl. admin keresőmező), másold ki a teljes hibasort,
• írd meg ticketben, milyen URL-t, mit csinálva kaptál hibát (pl. keresés admin felületen),
• mi a szabályazonosító alapján célzottan tudjuk vizsgálni, szükséges-e finomhangolás.

10. Deprecated / Notice hibák – régi kód, jövőbeni problémák

Példák:

PHP Deprecated:  Function create_function() is deprecated in /home/...
PHP Notice:  Undefined index: my_key in /home/...

Mit jelent?

• Deprecated: olyan függvényt vagy szintaxist használ a kód, ami újabb PHP verziókban már elavult, később el fog tűnni.
• Notice: nem kritikus, de jelzi, hogy valami nincs teljesen rendben (pl. nem létező tömbkulcs, változó).

Mit tehetsz?

• Ezek általában nem állítják meg a weboldalt, de hosszú távon problémát okozhatnak (PHP verzió váltásnál).
• Ha modern PHP verzióra váltasz, és sok Deprecated hibát látsz, fejlesztői oldalról érdemes a kódot frissíteni.
• Ha a log tele van Notice üzenetekkel, az ugyan nem kritikus, de takarja a valódi hibákat – fejlesztővel érdemes átnézetni.

Mikor és mit küldj el nekünk a logokból?

Ticket írása előtt érdemes összegyűjtened:

1. Melyik domain / aldomain érintett?
2. Mikor jelentkezett a hiba (dátum, idő, hozzávetőlegesen)?
3. Logrészlet a hiba idejéről:
   • Apache / Nginx kivonat a cPanel → Hibák (Errors) menüből,
   • PHP error logból 10–20 friss sor,
   • WordPress / Joomla debug.log vonatkozó része.

Ezt másold be a ticketbe:
https://ugyfeladmin.tarhely.eu/submitticket.php
Minél pontosabb logokat küldesz, annál gyorsabban és célzottabban tudunk segíteni.

Biztonság és teljesítmény – mire figyelj logolás közben?

• Ne hagyd feleslegesen bekapcsolva a debug módot (WordPress, Joomla, egyéb keretrendszerek):
  • logfájlok gyorsan nőnek,
  • érzékeny technikai információk (fájlstruktúra, path-ok, esetleg részleges adatok) kerülhetnek bele.
• Időnként ellenőrizd a logfájlok méretét, ha túl nagyok lettek:
  • töltsd le őket saját gépre archiválásra,
  • majd töröld a tárhelyről, hogy ne foglaljanak feleslegesen helyet.
• Logfájlokat ne tarts webből közvetlenül elérhető könyvtárban, vagy legalább biztosítsd, hogy ne legyenek böngészőn át letölthetők.

GYIK – Error logokkal kapcsolatos gyakori kérdések

1. Üres az error log. Akkor nincs hiba?

Nem feltétlenül.

Előfordulhat, hogy:

• a hiba nem PHP hiba, hanem például DNS / hálózati gond,
• a logolás nincs megfelelően bekapcsolva,
• másik logfájlt használ a rendszer.

Ilyenkor érdemes ellenőrizni a cPanel Hibák menüt, a PHP-FPM logs mappát és a CMS saját logját.

2. Nem jön létre a WordPress debug.log fájl. Mit rontottam el?

Ellenőrizd:

• hogy a wp-config.php-ben biztosan a megfelelő helyen és pontosan vannak-e a define sorok,
• hogy a wp-content mappának vannak-e írási jogosultságai,
• hogy van-e valamilyen cache / opcache, ami nem frissítette még a kódot.

Ha ezek rendben vannak, provokálj ki egy kisebb hibát (pl. ideiglenesen elírsz egy fájlnevet), és nézd meg, bekerül-e a logba.

3. Mekkora lehet a logfájl maximális mérete?

Konkrét felső korlát nincs, de gyakorlati okból érdemes figyelni rá:

• több száz MB-os vagy több GB-os log már feleslegesen terheli a tárhelyet,
• lassabb lehet a megnyitása, szerkesztése.

Ha nagyon nagyra nőtt, töltsd le, majd töröld vagy rotáld (új, üres logfájl jön létre a következő hiba esetén).

4. Kinyithatom a logfájlokat közvetlenül böngészőből?

Nem ajánlott.

• Biztonsági okból jobb, ha a logfájlok nem elérhetők közvetlenül HTTP-n keresztül.
• Használd a cPanel Fájlkezelőjét vagy FTP-t / SFTP-t a letöltésükhöz.

5. Hibát látok, de nem értem, mi a teendő – mit tegyek?

Semmi gond, ez teljesen normális.

Másold ki a hiba pontosan látható részét (időpont, üzenet, fájl/sor), és írj nekünk ticketet:

https://ugyfeladmin.tarhely.eu/submitticket.php

Mi a log alapján meg tudjuk mondani, hogy:

• tárhely / szerver beállítási kérdésről van szó, vagy
• inkább weboldal / fejlesztés oldalról kell javítani a hibát.