WordPress 7.0 / 7.1 frissítés után nem működik az oldalad? Ezek a tipikus okok

Frissítve: 2026. szeptember · Írta: Busai Gábor, 15+ év WordPress-tapasztalat

2026 a WordPress egyik legnagyobb váltásának éve volt. A 7.0 májusban, a 7.1 „Mary Lou" augusztus 19-én érkezett, és mindkettő hozott olyan változásokat, amitől addig évekig békésen működő oldalak dőltek ki.

Ha a te oldalad is közvetlenül egy frissítés után romlott el, ez a cikk végigvezet rajta: mi változott, melyik tünet melyik változáshoz tartozik, és mi a helyes sorrend a helyreállításhoz. Előre a legfontosabb: a visszaállítás ritkán a jó válasz.

Mi változott valójában?

WordPress 7.0 (2026. május)

• Minimum PHP 7.4. A PHP 7.2 és 7.3 támogatása megszűnt. A WordPress 7.x hivatalosan PHP 8.5-ig tesztelt.
• DataViews-alapú admin listák. A Bejegyzések, Oldalak és Média listaképernyőket újraépítették. Minden bővítmény, ami eddig oszlopokat adott hozzá, szűrőket tett be vagy máshogy nyúlt ezekhez a képernyőkhöz, kockázatos lett.
• Nincs új alapértelmezett sablon. A WordPress megszakította a hagyományt: nem érkezett „Twenty Twenty-Six".

WordPress 7.1 „Mary Lou" (2026. augusztus 19.)

• A szerkesztő iframe-esítése kötelezővé vált. A Block API 2-es vagy régebbi verzióját használó blokkokat frissíteni kell a 3-as verzióra, különben nem működnek rendesen a szerkesztőben.
• Kliensoldali képfeldolgozás. A WordPress már nem a szerveren méretezi a képeket – ez a böngészőben történik, feltöltés előtt. HEIC-konverzió, megbízhatóbb feltöltés, GIF-ből videó.
• jQuery UI 1.14.2. Minden régi bővítmény, ami jQuery UI-ra épül, érintett lehet.
• Reszponzív és hover állapotok a szerkesztőben, új Playlist és Tabs blokkok, új médiakezelő modál.

Ezek önmagukban jó változások. A baj abból lett, hogy sok bővítmény nem készült fel rájuk időben.

Először: tényleg a frissítés okozta?

Mielőtt bármit visszaállítanál, három perc alatt eldönthető:

1. Időbélyeg. Bejegyzések → nem, ide nem jutsz be, ha áll az oldal. Helyette: nézd meg a /wp-content/debug.log vagy a szerver error_log fájljának utolsó sorait, és hasonlítsd össze a frissítés időpontjával. Ha percre egyezik, megvan.
2. Mit mond a napló? Ha a hibaüzenetben egy konkrét bővítmény fájlja szerepel, akkor nem a WordPress tört el, hanem az a bővítmény nem bírta az új core-t. (A naplóolvasásról részletesen: Hol van a WordPress hibanapló, és hogyan olvasd?)
3. Frissült-e egyáltalán? Ha a frissítés félbeszakadt, más a teendő – lásd lentebb a „nem indul el a frissítés" részt.

Ha nincs semmilyen időbeli egybeesés, valószínűleg nem a frissítés a bűnös, és általános hibaelhárításra van szükség: „Kritikus hiba történt a webhelyén" – mit jelent, és hogyan javítsd.

A hét tipikus tünet és a javítása

1. Fehér képernyő vagy „kritikus hiba" közvetlenül a frissítés után

Ez a leggyakoribb. Egy bővítmény olyan core-funkciót hív, ami megváltozott, és végzetes hibát dob.

Volt erre egy tankönyvi eset a 7.1 megjelenése után: a népszerű WP Rocket gyorsítótárazó bővítmény Cloudflare-modulja dobott végzetes típushibát bizonyos beállításokkal, aminek nyomán oldalak fehéredtek ki. A naplóban a Cloudflare.php fájl szerepelt. A fejlesztő másnap kiadta a javítást tartalmazó verziót (3.23.2.2, 2026. augusztus 20.), a leírásában ezzel: „Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations."

A tanulság univerzális: ha egy nagy bővítmény akadt össze az új core-ral, nagy eséllyel más is így járt, a fejlesztő pedig órákon belül reagált. Először frissíts, ne visszaállíts.

Javítás:

1. Ha be tudsz lépni: frissíts minden bővítményt, kezdve a naplóban megnevezettel.
2. Ha nem tudsz belépni: FTP-n nevezd át a hibás bővítmény mappáját (például wp-rocket → wp-rocket-KI), lépj be, frissítsd, majd kapcsold vissza.
3. Ha nem tudod, melyik a bűnös: nevezd át az egész plugins mappát plugins-KI-re, lépj be, nevezd vissza, és egyesével kapcsold be őket.

2. Az admin bejegyzés- vagy oldallista üres, törött, vagy hiányoznak az oszlopok

Ok: a 7.0 DataViews-átállása. Ha egy bővítmény a régi WP_List_Table logikára épített – saját oszlopokra, tömeges műveletekre, szűrőkre –, az most nem illeszkedik.

Javítás: frissítsd az admin felületet módosító bővítményeket (egyedi mezők, SEO, WooCommerce-kiegészítők, médiakezelők). Ha egy bővítményhez nincs frissítés, és hónapok óta nem is volt, az önmagában figyelmeztető jel: ideje leváltani.

3. A szerkesztő nem tölt be, vagy a blokkok szétesnek benne

Ok: a 7.1-ben kötelezővé vált iframe-es szerkesztő. A Block API 2-es vagy régebbi verzióját használó egyedi blokkok nem működnek helyesen, és a szerkesztőre írt saját CSS sem érvényesül úgy, mint korábban.

Javítás: frissítsd a blokkokat adó bővítményeket. Egyedi, saját fejlesztésű blokknál a block.json fájlban az apiVersion értéket kell 3-ra emelni, és az eddig globálisan betöltött szerkesztői stílusokat az iframe-be kell juttatni. Fontos: ez a tünet csak a szerkesztőt érinti – a látogatók rendben látják az oldalt. Nem vészhelyzet, de bosszantó.

4. Képfeltöltési furcsaságok a 7.1 után

Ok: a kliensoldali képfeldolgozás. A méretezés és a formátumkonverzió a böngészőben történik, feltöltés előtt.

Ez a legtöbb helyen javulás – de: régi böngészőben, gyenge gépen vagy nagyon nagy képeknél a feltöltés lassabbnak tűnhet, mert a munka a felhasználó gépén zajlik. Emellett a képoptimalizáló bővítmények egy része a szerveroldali feldolgozásra épült, és most üresben jár.

Javítás: frissítsd a képoptimalizáló és médiakezelő bővítményeket, és ellenőrizd, hogy a feltöltött képek tényleg a várt méretben és formátumban jönnek létre. Ha valami nem stimmel, a funkció kikapcsolható – de előbb a bővítményfrissítést próbáld.

5. A frissítés el sem indul, vagy félbeszakad

Ok: jellemzően a PHP-verzió. A WordPress 7.x nem települ PHP 7.2 vagy 7.3 alatt. Másik gyakori ok: időtúllépés vagy memóriahiány a frissítés közben.

Tünet: az oldalon beragad a „Rövid ideig nem érhető el ütemezett karbantartás miatt" üzenet. Ilyenkor FTP-n törölni kell a gyökérkönyvtárban lévő .maintenance fájlt, és ellenőrizni, hogy a frissítés befejeződött-e.

Javítás: a tárhely vezérlőpultján állítsd a PHP-t legalább 8.1-re (lehetőleg 8.3-ra), és indítsd újra a frissítést. Ha a PHP-váltás önmagában okoz hibát, akkor előbb a bővítmények és a sablon PHP 8 kompatibilitását kell rendezni.

6. Eltűnt vagy megváltozott a sablon

Ok: a 7.0 óta nincs új alapértelmezett sablon. Ha valamiért a WordPressnek alapsablonra kellene visszaállnia – például hiba miatt –, és a szerveren nincs ott egyik régi Twenty-* sablon sem, az oldal formázás nélkül jelenik meg.

Javítás: tarts mindig egy alapértelmezett sablont telepítve (nem aktiválva) a szerveren. Ez hibaelhárításkor is aranyat ér, mert így egy kattintással kizárható, hogy a sablon okozza a bajt.

7. Naplóelárasztás Deprecated sorokkal

Ok: az új core és az újabb PHP olyan függvényhívásokat jelez elavultnak, amiket a régi bővítmények még használnak.

Ezek nem törik el az oldalt – de megtöltik a naplófájlt, lassíthatnak, és pontos listát adnak arról, mi fog eltörni a következő frissítésnél. Nézd át, melyik bővítmény termeli a legtöbbet, és azokat cseréld le előbb.

Mit tegyél most, ha már eltört – a helyes sorrend

1. Mentés a jelenlegi, hibás állapotról. Fájlok és adatbázis. Ez lesz a visszaút, ha a javítás rosszul sül el.
2. Nézd meg a naplót. Ez mondja meg, melyik bővítmény a bűnös. Találgatás helyett két perc olvasás.
3. Frissíts minden bővítményt és a sablont. Ez oldja meg az esetek nagy részét, mert a fejlesztők már kiadták a javítást.
4. Ha ettől sem jó: kapcsold ki a gyanús bővítményt, és nézd meg, él-e az oldal. Ha igen, megvan a bűnös – keress alternatívát vagy várd meg a javítást.
5. Ellenőrizd a PHP-verziót. Legalább 8.1, inkább 8.3.
6. Csak ezek után gondolkodj visszaállításon.

Miért utolsó lehetőség a visszaállítás?

Mert három problémát hoz magával:

• Biztonsági kockázat. A régi core-verzió nem kap biztonsági javítást, és a frissítésekben szereplő sérülékenységek nyilvánosak. Egy visszaállított WordPress lényegében kiírja magáról, hogy támadható.
• Adatvesztés. Ha adatbázis-mentést is visszaállítasz, a frissítés óta érkezett rendelések, űrlapbeküldések, hozzászólások eltűnnek.
• Csak halasztás. A frissítést előbb-utóbb meg kell csinálni – a probléma nem oldódik meg magától.

Van egy eset, amikor mégis indokolt: ha webshop áll, pénz áll vele, és a javításra várni kell. Ilyenkor a visszaállítás ideiglenes megoldás, amit napokon belül követnie kell a rendes frissítésnek – lehetőleg staging környezetben tesztelve.

„De én nem is frissítettem semmit!"

Ezt hallom a leggyakrabban – és általában igaz is. Három módon frissülhet az oldalad anélkül, hogy te bármit tettél volna:

• A WordPress automatikus frissítései. A kisebb, biztonsági kiadások (7.1.1, 7.1.2) alapból automatikusan települnek. Sok oldalon a nagy verziók is, ha valaki egyszer bekapcsolta.
• Bővítmények automatikus frissítése. Ez bővítményenként külön beállítható, és sokan bekapcsolják, aztán elfelejtik. Ilyenkor éjjel kettőkor frissül valami, reggel nyolckor pedig áll az oldal.
• A tárhelyszolgáltató. Managed WordPress csomagoknál a szolgáltató frissíthet – core-t, PHP-t, néha bővítményt is. A PHP-verzió emelése különösen gyakori, és jellemzően előre jelzik e-mailben, amit senki nem olvas el.

Mit nézz meg: az adminban a Vezérlőpult → Frissítések oldalon látszik a jelenlegi core-verzió; a tárhely vezérlőpultján a PHP-verzió és annak váltási dátuma. Ha a hiba időpontja egybeesik valamelyikkel, megvan a válasz – és onnantól a fenti javítási sorrend ugyanaz.

Frissítés utáni ellenőrzőlista – 10 perc, 10 pont

Ezt érdemes minden nagyobb frissítés után végigfutni. A legtöbb hiba nem a nyitóoldalon látszik, hanem ott, ahova senki nem néz rá:

1. Nyitóoldal betölt, kijelentkezve is (nem csak adminként, mert a gyorsítótár mást mutathat).
2. Egy aloldal és egy blogbejegyzés – nem 404-es?
3. A kapcsolati űrlap: küldj el egy próbaüzenetet, és nézd meg, meg is érkezik-e.
4. Webshopnál: termékoldal, kosár, pénztár, és egy próbarendelés a végéig.
5. Bejelentkezés és az admin felület – a bejegyzéslista rendben jelenik meg?
6. Egy bejegyzés megnyitása szerkesztésre: betölt a szerkesztő, látszanak a blokkok?
7. Képfeltöltés a médiatárba – létrejönnek a méretek?
8. Mobil nézet egy valódi telefonon, nem csak a böngésző szimulátorában.
9. A hibanapló: van-e új Fatal error az utolsó órából?
10. Google Search Console: érkezett-e új lefedettségi hiba a következő napokban?

Hogyan frissíts legközelebb, hogy ne legyen ebből baj

A frissítés utáni hibák túlnyomó része megelőzhető. A sorrend számít:

1. Mentés a frissítés előtt. Nem havonta – közvetlenül előtte.
2. Először a bővítmények és a sablon, utána a core. Ez a legfontosabb szabály, és a legtöbben pont fordítva csinálják. A bővítményfejlesztők előre kiadják a kompatibilis verziót; ha azokkal indulsz, a core-frissítés már sima ügy.
3. Ne egyszerre. Ha tíz bővítményt frissítesz egy kattintással, tíz gyanúsítottad lesz. Csoportokban frissíts, és nézz rá az oldalra közben.
4. Nagyobb verzióváltásnál staging. Egy 7.0 → 7.1 típusú lépésnél a másolaton tesztelés nem luxus. A legtöbb jobb tárhelyen egy kattintás.
5. Várj egy-két hetet a nagy kiadásokkal. Nem a WordPressben nem lehet megbízni – hanem a bővítményekben, amik alkalmazkodnak hozzá. A 7.1 esetében is pár nap alatt kijöttek a javítások.
6. A core automatikus frissítése maradhat bekapcsolva, a bővítményeké inkább ne. Azok törnek el gyakrabban, és éjjel fél háromkor senki nem nézi az oldalt.

Ha ez több figyelmet igényel, mint amennyit erre szánni szeretnél, pontosan erre való a havi WordPress karbantartás: felügyelt frissítés, mentés előtte, és ha mégis baj van, nem neked kell hibanaplót olvasnod hétfő reggel.

Gyakori kérdések

Kapcsolódó olvasnivaló: „Kritikus hiba történt a webhelyén" · Hol van a WordPress hibanapló? · Miért fontos a havi karbantartás és a saját mentés?