Ha 2026. augusztus 19-e után fehér képernyőt vagy „Kritikus hiba történt a webhelyen” üzenetet kaptál, és a wp-adminba sem tudsz belépni, jó eséllyel nem te hibáztál. A WordPress 7.1 megjelenése és a WP Rocket gyorsítótárazó bővítmény egyik modulja ütközött egymással, és több ezer oldal állt le tőle egyetlen éjszaka alatt.
Mi történt 2026. augusztus 19-én?
Aznap jelent meg a WordPress 7.1 „Mary Lou”, 800-nál is több közreműködő munkájával. Egy órákkal későbbi, teljesen hétköznapi frissítés után elkezdtek dőlni az oldalak.
Másnap hajnalban a WP Rocket fejlesztője, a WP Media hivatalos incidenst nyitott a státuszoldalán „WP Rocket incompatibility with WordPress 7.1″ címmel. Az idővonal szerint 05:44-kor azonosították a hibát, 08:14-kor kiadták a javítást, 10:15-kor lezárták az incidenst. A hivatalos changelogba ez a mondat került:
„Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations” — WP Rocket 3.23.2.2, 2026. augusztus 20.
Vagyis: a hiba valós, a gyártó elismerte, és van rá javítás. A gond az, hogy addigra sok oldal már órák óta állt — és a tulajdonosuk nem tudott róla.
Honnan tudod, hogy nálad is ez a hiba van?
Egyetlen dolgot keress. A tárhelyed hibanaplójában, vagy abban a levélben, amit a WordPress küld „A webhelyen kritikus hiba lépett fel” tárggyal, keresd ezt a szövegrészletet:
`Cloudflare.php:562`
Ha ez szerepel benne, akkor ez a konkrét eset. A jelenség tipikusan így néz ki:
| Amit tapasztalsz | Ide illik ez a hiba? |
|---|---|
| Fehér képernyő vagy „Kritikus hiba" a nyilvános oldalon és az adminban is | Igen — ez a hiba minden belépési pontot megöl |
| Csak a wp-admin lassú, de működik | Nem, ez más probléma |
| Van WP Rocket az oldaladon, és a WordPress 7.1-re frissítettél | Igen, ez a fő gyanú |
| WordPress 7.0.x fut nálad | Nem — a 7.0-s ágat ez nem érintette |
| Ismeretlen admin-fiók vagy idegen fájlok is vannak | Nem ez, itt feltörésre utaló jeleket keress |
Fontos: ez nem feltörés. Sok oldaltulajdonos ilyenkor először támadásra gyanakszik, és pánikba esik. Itt egy programozási hibáról van szó — a bővítmény olyan adatot kapott a WordPresstől, amilyenre nem volt felkészítve, és megállt a futás.
Miért omlott össze az oldalad akkor is, ha mindent frissen tartottál?
Ez a történet legkellemetlenebb része. Az érintett oldalak naprakészek voltak: friss WordPress, friss, fizetős WP Rocket. Aki halogatta a frissítést, az megúszta.
A technikai elemzést elvégző Wordify így fogalmazott: senki nem csinált semmit rosszul. Stabil WordPress-kiadás, teljesen naprakész prémium bővítmény, rutinfrissítés — és az oldal mégis keményen leállt.
Két dolog teszi ezt különösen alattomossá:
• Nem kell Cloudflare-t használnod ahhoz, hogy a Cloudflare-modul megölje az oldaladat. Ez a modul minden kérésnél lefut, akkor is, ha a szolgáltatáshoz semmi közöd.
• Önmagában a WP Rocket sem omlott össze. Kellett hozzá egy harmadik bővítmény is — a dokumentált esetekben tipikusan az Elementor Pro, ami a magyar piacon rendkívül elterjedt. Vagyis a hiba a bővítmények *kombinációjából* fakadt. Pontosan abból, amit senki nem tesztel előre.
És van egy adat, amit érdemes megjegyezni: a hibát hat héttel korábban, 2026. július 6-án bejelentették a WP Rocket nyilvános hibakövetőjében, javasolt javítással együtt. A 7.1 megjelenéséig nem került be. Ezt a The Repository szaklap tárta fel, és a gyártó azóta belső vizsgálatot ígért.
Mennyire gyakori ez? Nem csak veled történt meg
Néhány szám, ami segít elhelyezni:
Egy professzionálisan üzemeltetett tárhelyflottában 332 WP Rocketes oldalból 124 kapott végzetes hibát a 7.1 után — vagyis több mint a harmaduk. Ez szakértők által felügyelt környezetben történt. (The Repository, 2026. augusztus)
A Wordify naplói szerint a core frissítése után három másodperccel megjelent az első végzetes hiba. Nincs „majd észreveszem” fázis: ha éjszaka fut le a frissítés, reggelig áll az oldalad. (Wordify, 2026. augusztus 20.)
A magyar érintettség pedig átlag feletti. A wmtips technológiai felmérése szerint Magyarországon a WP Rocket a második legnépszerűbb gyorsítótárazó megoldás 12,6%-os részesedéssel, szemben a 9,1%-os világátlaggal. Vagyis a magyar WordPress-oldalak arányaiban jobban ki voltak téve ennek, mint a nemzetközi átlag.
Mit ne csinálj most, amíg nem érted a helyzetet
Ez a szakasz nem a javításról szól, hanem arról, hogyan ne tedd tönkre végleg azt, ami még menthető. A leggyakoribb kapkodó lépések:
• Ne töröld ki magát a hibás fájlt. A gyártó a saját súgójában is kifejezetten óv ettől: az érintett osztály be van kötve a bővítmény belső szerkezetébe, így a törlésével csak egy másik végzetes hibát kapsz — és onnan már nehezebb visszatalálni.
• Ne állítsd vissza a WordPresst egy régebbi verzióra. Egy visszaléptetett core adatbázis-szinten okozhat olyan bajt, ami nagyságrendekkel drágább, mint az eredeti probléma.
• Ne nyúlj semmihez mentés nélkül. Mielőtt bármit módosítanál a tárhelyen, legyen egy pillanatkép a jelenlegi állapotról. Ha nincs friss, visszatölthető mentésed, arról külön írtunk a 3-2-1 mentési szabályról szóló cikkünkben.
• Ne kérj meg egy ismerőst, hogy „nézzen bele gyorsan FTP-vel”. Ennél az esetnél a szokásos mentőutak — köztük a parancssoros eszközök — szintén megállnak, mert a hiba korábban lép fel, mint ahova a segédeszközök odaérnének. Aki nem ismeri a pontos sorrendet, könnyen ront a helyzeten.
Akkor mégis mi a tanulság? Nem az, hogy ne frissíts
Kísértést érezhetsz arra, hogy a jövőben inkább ne nyúlj a frissítésekhez. Ez rossz irány, és sokkal többe kerülne.
A nem frissített oldal a legkiszámíthatóbb célpont: a WordPress 7.0.2 esetében az első támadási kísérletek 90 perccel a javítás megjelenése után befutottak. A halogatás tehát nem biztonság, csak halasztott kockázat. A bővítményválasztás minőségéről pedig külön szóltunk a pluginválasztásról írt cikkünkben.
Az igazi különbség nem abban van, hogy frissítesz-e, hanem abban, hogy milyen körülmények között: van-e tesztkörnyezet, van-e visszatölthető mentés, jó sorrendben megy-e a frissítés, és van-e valaki, aki hajnali kettőkor is látja, ha megáll az oldal.
Nálunk a karbantartási csomagos ügyfelek ebből semmit nem éreztek
A WP Pajzs karbantartási csomagjában lévő oldalakon ezt az esetet természetesen megoldottuk — az ügyfeleink nagy része arról értesült, hogy volt egy probléma, amit már el is hárítottunk. Pontosan ezért létezik a szolgáltatás: nem attól lesz biztonságos egy oldal, hogy soha nem történik vele semmi, hanem attól, hogy amikor történik, van, aki azonnal észreveszi és kezeli.
Ha most a te oldalad áll, és nem tudod, hol kezdd: kérd az ingyenes biztonsági gyorsellenőrzésünket. Megnézzük, valóban ez a hiba van-e nálad, milyen állapotban van az oldalad, és megmondjuk, mi kell a helyreállításhoz. Tizenöt perc, és tudni fogod, hol állsz.
*Források: WordPress.org — WordPress 7.1 „Mary Lou” (2026. augusztus 19.); WP Rocket changelog — 3.23.2.2 (2026. augusztus 20.); WP Media státuszoldal — WP Rocket incompatibility with WordPress 7.1; WP Rocket tudásbázis — Fatal error on WordPress 7.1; The Repository (2026. augusztus 21.); Wordify technikai elemzés (2026. augusztus 20.); wmtips — cache-technológiák Magyarországon.*
Gyakori kérdések
Miért omlott össze az oldalam a WordPress 7.1 frissítés után?
Ha WP Rocket fut az oldaladon, jó eséllyel a bővítmény Cloudflare-moduljának egy sora ütközött a WordPress 7.1 egyik belső változásával. A WP Rocket gyártója 2026. augusztus 20-án hivatalos incidensben ismerte el a hibát, és még aznap kiadta a javítást tartalmazó 3.23.2.2-es verziót. A WordPress 7.0.x verziókat ez nem érintette.
Honnan tudom, hogy tényleg ez a hiba van nálam?
A hibanaplóban vagy a WordPress kritikus hibáról szóló levelében keresd a Cloudflare.php:562 szöveget. Ha ez szerepel benne, akkor ez a konkrét eset. Ilyenkor nemcsak az admin felület áll, hanem a nyilvános oldal, a REST API és az ütemezett feladatok is.
Feltörték az oldalamat?
Ebben az esetben szinte biztosan nem. Ez egy programozási hiba, nem támadás: a bővítmény olyan adatot kapott a WordPresstől, amilyenre nem számított, és emiatt megállt a futás. Feltörésre más jelek utalnak, például ismeretlen adminisztrátor-fiók vagy idegen fájlok a feltöltések között.
Akkor jobban jártam volna, ha nem frissítek?
Nem. A halogatott frissítés hosszú távon nagyobb kockázat: a publikált, de be nem foltozott hibákat napok alatt elkezdik támadni. A megoldás nem a frissítés elhagyása, hanem a sorrend és a körülmények kézben tartása — tesztkörnyezet, mentés, ellenőrzött ütemezés.
Miért omlott össze az oldalam akkor is, ha nem használok Cloudflare-t?
Mert a WP Rocket Cloudflare-modulja minden kérésnél lefut, függetlenül attól, hogy be van-e kapcsolva a Cloudflare. Ezért érte váratlanul azokat is, akiknek semmi közük nem volt a szolgáltatáshoz.
