„Kritikus hiba történt a webhelyén” – mit jelent, és hogyan javítsd lépésről lépésre

Egy hétfő reggel, egy telefon: „Gábor, nem jön be az oldal. Csak egy szürke szöveg van rajta, hogy kritikus hiba." Ez a WordPress leggyakoribb vészjelzése, és bár elsőre úgy fest, mintha mindent elvesztettél volna, a helyzet a legtöbb esetben sokkal jobb, mint amilyennek látszik.

Ebben az útmutatóban végigmegyünk azon, hogy mit jelent pontosan ez az üzenet, hogyan derítsd ki tíz perc alatt a valódi okát, és hogyan állítsd helyre az oldalt – akkor is, ha épp be sem tudsz lépni az adminba.

Mit jelent valójában ez az üzenet?

A WordPress 5.2 óta van egy beépített védőháló, a fatal error handler. Amikor a PHP-kód futása közben olyan hiba történik, amiből nincs visszaút – egy nem létező függvényt hív meg valami, egy fájl hiányzik, elfogy a memória –, a WordPress nem hagyja, hogy a látogató nyers PHP-hibaüzenetet lásson (ami ráadásul szervernevet és fájlútvonalat is elárulna). Helyette kiírja ezt a semmitmondó, de biztonságos mondatot.

Két változatot láthatsz:

• „Kritikus hiba történt a webhelyén." – ezt látja a látogató.
• „Kritikus hiba történt a webhelyén. Kérjük, nézze meg a webhely adminisztrátori e-mail postafiókját az utasításokért." – ezt látod te, amikor a WordPress már ki is küldte a hibajavító levelet.

A második változat jó hír: van hova kapaszkodni.

Amit fontos érteni: ez nem hibaüzenet a szó szoros értelmében, hanem egy elrejtett hibaüzenet. A valódi ok – a fájl neve és a sor száma, ahol elszállt – ott van a szerveren, csak nem látszik. Az egész hibaelhárítás arról szól, hogy ezt előhozzuk.

Mit NE csinálj elsőként

Mielőtt bármihez hozzányúlnál, három dolog, ami sok oldalt vitt már sírba:

1. Ne telepítsd újra a WordPresst „a biztonság kedvéért". Ha nem tudod, mi a hiba, az újratelepítés csak elfedi, vagy elviszi a testreszabásaidat.
2. Ne törölj fájlokat találomra. Különösen ne az wp-content alatt.
3. Ne állítsd vissza azonnal egy régi mentésből, ha nem tudod, mikor keletkezett a hiba. Ha közben rendelések, űrlapbeküldések, hozzászólások érkeztek, azok elvesznek.

1. lépés: nézd meg a hibajavító mód levelet

A WordPress ilyenkor automatikusan küld egy e-mailt az adminisztrátori címre. Fontos: nem a te felhasználói e-mail-címedre, hanem arra, ami a Beállítások → Általános menüben adminisztrátori e-mail-címként szerepel. Ez sok oldalon egy régi, elfelejtett cím.

A levél tárgya: „A webhelyed technikai problémákat tapasztal" vagy angolul „Your Site is Experiencing a Technical Issue". És ami a legértékesebb benne: megnevezi a hibás bővítményt vagy sablont, és megadja a pontos hibaüzenetet, például:

Hiba részletei
==============
Egy PHP hiba történt a webhelyeden.

Hibatípus: E_ERROR
Fájl: /wp-content/plugins/valami-bovitmeny/includes/class-main.php
Sor: 218
Üzenet: Uncaught Error: Call to undefined function wp_get_valami()

Ez a négy sor általában elég a diagnózishoz. A levélben van egy link is, amivel hibajavító módban (recovery mode) be tudsz lépni az adminba: ilyenkor a WordPress kikapcsolja a hibát okozó bővítményt, és beenged téged.

Ha nem jött meg a levél, annak három tipikus oka van: rossz az adminisztrátori cím, a levél a spam mappában van, vagy – és ez a leggyakoribb – az oldalad egyáltalán nem tud e-mailt küldeni. Ez utóbbi önmagában is javítandó probléma; erről külön írtam a Miért nem kapom meg a levelet? cikkben.

Ha nincs levél, megyünk tovább – akkor kézzel hozzuk elő a hibát.

2. lépés: kapcsold be a hibanaplózást

Ehhez hozzá kell férned a fájlokhoz: FTP-n (FileZilla), SFTP-n, vagy a tárhely fájlkezelőjén keresztül.

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

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

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

Ez FÖLÉ illeszd be a következőt:

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

Mit csinál ez a négy sor?

• WP_DEBUG – bekapcsolja a hibajelentést.
• WP_DEBUG_LOG – a hibákat egy fájlba írja, nem a képernyőre.
• WP_DEBUG_DISPLAY false – ez a lényeg: a látogatók nem fogják látni a hibákat. Élő oldalon soha ne írasd ki a hibákat a képernyőre, mert az szerverútvonalakat és adatbázis-információt szivárogtat.

Mentsd a fájlt, majd töltsd be újra az oldalt (vagy azt az admin oldalt, ahol a hiba jelentkezik). Ezzel megszületik a naplófájl.

Keresd meg: /wp-content/debug.log

Nyisd meg, és görgess a legaljára – a legfrissebb bejegyzés van legalul. Amit keresel, az egy ilyen sor:

[04-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

A három kulcsinformáció:

Ha a debug.log nem jön létre, a szervernek is van saját naplója – cPanel alatt általában error_log néven a gyökérben vagy a public_html-ben.

3. lépés: a hat leggyakoribb ok és a javításuk

A naplósor birtokában már nem tapogatózol. Íme, amivel a gyakorlatban a leggyakrabban találkozom.

1) Bővítményütközés vagy hibás bővítményfrissítés

Tünet a naplóban: az útvonalban /wp-content/plugins/… szerepel.
Tipikus üzenet: Call to undefined function, Cannot redeclare, Class not found.

Ez a leggyakoribb eset, és általában egy frissítés után jelentkezik: két bővítmény ugyanazt a függvényt akarja definiálni, vagy az egyik olyan funkcióra épít, ami a másik új verziójából kikerült.

Javítás, ha be tudsz lépni: Bővítmények → kapcsold ki a naplóban megnevezettet.

Javítás, ha nem tudsz belépni (ez a gyakoribb):

1. FTP-n menj a /wp-content/plugins/ mappába.
2. Nevezd át a hibás bővítmény mappáját, például pelda-bovitmeny → pelda-bovitmeny-KI.
3. Töltsd újra az oldalt. A WordPress nem találja a bővítményt, ezért egyszerűen kikapcsolja.

Ha nem tudod, melyik a bűnös, nevezd át az egész plugins mappát plugins-KI-re. Ezzel minden bővítmény kikapcsol. Ha az oldal életre kel, nevezd vissza, majd egyesével kapcsold be őket, amíg a hiba vissza nem tér. Nyolc bővítménynél ez akár három lépésben is megvan, ha felezéssel csinálod.

2) A sablon (téma) hibája

Tünet: az útvonal /wp-content/themes/…

Gyakori, ha egyedi kódot tettél a functions.php-be (például egy internetről másolt snippetet), vagy ha a sablon régi és nem kompatibilis az új PHP-verzióval.

Javítás: ha be tudsz lépni, válts ideiglenesen egy alapértelmezett sablonra. Ha nem tudsz belépni, FTP-n nevezd át az aktív sablon mappáját – a WordPress ilyenkor automatikusan visszaáll egy alapértelmezett sablonra, ha az elérhető a szerveren. Ezért érdemes mindig ott hagyni egy alap sablont, még ha nem is használod.

Ha csak a functions.php-ben rontottál el valamit, és tudod, mit írtál bele utoljára: nyisd meg FTP-n, és vedd ki a legutóbb beszúrt blokkot.

3) PHP-verzió eltérés

Tipikus üzenet: syntax error, unexpected ':', Deprecated, vagy a wp-includes alól jövő hiba.

Ez akkor jelentkezik, ha a tárhely megemelte (vagy visszavette) a PHP-verziót, és a sablon vagy egy bővítmény nem bírja. 2026-ban a WordPress 7.x minimum PHP 7.4-et igényel, és PHP 8.5-ig tesztelt; a PHP 7.2 és 7.3 támogatása megszűnt. Ha valami PHP 5-ös korból származó kód van az oldalon, az egy PHP 8-as váltásnál végzetes hibát dob.

Javítás: a tárhely vezérlőpultján állítsd vissza ideiglenesen az előző PHP-verziót, hogy az oldal éljen – aztán ne hagyd ott. A régi PHP lassabb és biztonsági kockázat. A tényleges megoldás a hibás bővítmény vagy sablon frissítése, illetve cseréje.

4) Elfogyott a memória

Tipikus üzenet: Allowed memory size of 268435456 bytes exhausted.

Javítás első körben: a wp-config.php-ban, szintén a „stop editing" sor fölé:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Ha ez nem hat, a szerver php.ini vagy .user.ini fájljában, illetve a tárhely PHP-beállításainál kell emelni a memory_limit értéket.

Figyelem: ha az emelés után is elfogy a memória, akkor nem a korlát a baj, hanem valami elszabadult – egy végtelen ciklus, egy rossz adatbázis-lekérdezés vagy egy memóriaszivárgás. Ilyenkor az emelés csak késlelteti az összeomlást.

5) Sérült vagy hiányzó core fájl

Tünet: a hiba a /wp-includes/ vagy /wp-admin/ mappából jön, gyakran require_once(): Failed opening required üzenettel.

Ez megszakadt frissítés, hibás fájlfeltöltés vagy tárhelyprobléma után fordul elő.

Javítás: töltsd le a hu.wordpress.org oldalról a saját verziódnak megfelelő telepítőt, csomagold ki, és FTP-n írd felül a wp-admin és wp-includes mappákat, valamint a gyökérben lévő fájlokat. A wp-content mappához és a wp-config.php-hoz ne nyúlj – abban van minden tartalmad és beállításod.

6) Feltörés

Tünet: a hiba olyan fájlból jön, amit nem ismersz fel; a naplóban base64_decode, eval( vagy hosszú, értelmetlen karakterláncok szerepelnek; a wp-content/uploads mappában PHP-fájlok vannak (ott sosem szabadna lenniük).

Ez a legkellemetlenebb forgatókönyv, mert itt a látható hiba csak tünet. A kártékony kód eltávolítása önmagában nem elég: ha marad hátsó ajtó, napokon belül visszatér. Ilyenkor a helyes sorrend: izolálás, mentés, jelszó- és sózókulcs-csere, hátsó ajtók felkutatása, tiszta újratelepítés, és csak ezután a blacklist-feloldás.

Ha erre gyanakszol, ne kísérletezz tovább.

Ha semmi nem működik: belépés az adatbázison keresztül

Van egy eset, amikor a fenti lépések sem visznek előre: az oldal fehér, a bővítmények mappáját átnevezted, a sablont is – és még mindig kritikus hiba van.

Ilyenkor a wp-config.php-ban ideiglenesen kikapcsolhatod magát a hibakezelőt, hogy lásd a nyers PHP-hibát:

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

Ez azért hasznos, mert a hibakezelő néha maga is elbukik (például ha a hiba nagyon korán, az alap fájlok betöltése közben történik), és ilyenkor a „kritikus hiba" üzenet is félrevezető lehet. Ha kikapcsolod, a debug.log sokkal beszédesebb lesz.

Ugyanígy, ha a sablont adatbázisból akarod váltani, a phpMyAdminban a wp_options táblában a template és stylesheet sorokat kell átírnod egy létező sablon mappanevére. Előtte exportáld a táblát.

Speciális eset: WordPress 7.0 / 7.1 frissítés után

2026-ban ez külön figyelmet érdemel. A WordPress 7.0 (2026. május) és 7.1 (2026. augusztus) több olyan változást hozott, amitől jól működő bővítmények is elszálltak:

• Minimum PHP 7.4 – a régebbi PHP-n futó oldalakon a frissítés eleve elakad.
• DataViews-alapú admin listák – minden bővítmény, ami a bejegyzés- vagy oldallistát módosította, kockázatos.
• A szerkesztő iframe-esítése – egyedi blokkoknál és szerkesztői stílusoknál okozhat gondot.
• Nincs új alapértelmezett sablon – aki „Twenty Twenty-Six"-ra számított, meglepetést kap.

Volt konkrét, széles körű eset is: a 7.1 megjelenése után egy népszerű gyorsítótárazó bővítmény Cloudflare-modulja dobott végzetes típushibát, amitől oldalak százai fehéredtek ki – a fejlesztő másnap kiadta a javítást. A tanulság: ha közvetlenül egy WordPress-frissítés után jelent meg a kritikus hiba, először a bővítményeidet frissítsd, ne a WordPresst állítsd vissza. Nagy eséllyel már van javítás.

Hogyan előzd meg legközelebb

A kritikus hiba szinte mindig frissítés utáni állapot. Ezért a megelőzés is a frissítési szokásaidon múlik:

1. Frissítés előtt mentés, mindig. Nem havonta – frissítés előtt.
2. Ne frissíts mindent egyszerre. Ha tíz bővítményt frissítesz egy kattintással, és elszáll az oldal, tíz gyanúsítottad van. Csoportokban frissíts.
3. Legyen staging (másolat) oldalad, ha webshopod vagy komolyabb oldalad van. Ott először, éles oldalon utána.
4. A core automatikus frissítése maradjon bekapcsolva, de a bővítmények automatikus frissítését inkább kapcsold ki – azok törnek el gyakrabban.
5. Legyen saját mentésed, ne csak a tárhelyé. Erről írtam bővebben: Miért fontos a havi karbantartás és a saját biztonsági mentés a WordPress-nél?
6. Tartsd naprakészen a PHP-verziót – ütemezetten, tesztelve, nem akkor, amikor a tárhely rád kényszeríti.

Ha ez több figyelmet igényel, mint amennyit szeretnél rá fordítani, erre való a havi WordPress karbantartás: a frissítések felügyelve futnak, van mentés, és ha mégis baj van, nem neked kell hibanaplót olvasnod.

Gyakori kérdések