WordPress 7.2 érkezik decemberben: mire készülj oldaltulajdonosként és fejlesztőként?

Elindult a WordPress 7.2 kiadási ciklusa: a WordPress core csapat menetrendje szerint az első béta 2026. október 20-a és 22-e között, a végleges verzió pedig december 8-a és 10-e között jelenik meg, a kiadást Matt Mullenweg, a WordPress társalapítója vezeti. A decemberi dátum elsőre kényelmesen távolinak tűnik, a nyári 7.1 azonban olyan mélyreható változásokat hozott a szerkesztőbe (képernyőméret szerinti blokkstílusok, gombállapotok, minden bejegyzéstípusnál iframe-be zárt szerkesztő), amelyek hatását sok céges oldalon valószínűleg még senki sem nézte meg alaposan, a 7.2-re tervezett újdonságok pedig éppen ezekre épülnek tovább. Aki most kezd hozzá, annak nyugodt tizenegy hete marad a felkészülésre, aki viszont decemberben kapja fel a fejét, annak jó eséllyel egy karácsony előtti hibaelhárítás jut.

A fejlesztői oldalon már most van kézzelfogható változás, hiszen 2026. szeptember 8-tól a WordPress és a Gutenberg fejlesztői tárolói Node.js 24.18.0-t és npm 11.16.0-t kérnek, a Site Editor v2 és a nyilvánossá váló DataViews-komponensek pedig azt jelzik, hogy a WordPress adminfelülete a következő kiadásokban alaposan átalakul. A folytatásban 2026. szeptember 22-i állapot szerint végigvesszük a menetrendet, a 7.2 tervezett funkcióit (amelyekről a core csapat maga is jelzi, hogy nem mind kerül be a végleges kiadásba), a PHP- és Node.js-követelményeket, azt, hogy mit érdemes tesztelni a 7.1 responsive stílusai és ikonregisztrációja után, végül egy lépésről lépésre haladó felkészülési tervet adunk becsült időigénnyel és költséggel.

Röviden

• A WordPress 7.2 első bétaverziója 2026. október 20-a és 22-e között, a végleges kiadás december 8-a és 10-e között várható, a kiadást Matt Mullenweg vezeti, a koordinációt David Baumwald végzi, a technikai vezetők pedig George Mamadashvili és Peter Wilson.
• A core csapat 2026. szeptember 18-i roadmapje szerint a 7.2 többek között az űrlapelemek stílusozását a Global Styles felületen, bővített responsive stílusokat, szerkesztési javaslatokat a Notes funkcióban, új biztonsági eszközöket (Secrets API, sudo mód) és egy bővíthető webhelyszerkesztőt céloz, a csapat azonban maga írja, hogy nem minden tervezett elem kerül be a végleges kiadásba.
• Az éles oldalhoz várhatóan nem kell új PHP-verzió, mert az általunk átnézett 7.2-es anyagok nem említenek minimumemelést: a WordPress 7.0 óta a legalacsonyabb támogatott változat a PHP 7.4.0, az ajánlott pedig a PHP 8.3.
• A 2026. szeptember 8-tól érvényes Node.js 24.18.0 és npm 11.16.0 követelmény csak a WordPress és a Gutenberg fejlesztői build-eszközeit érinti, az éles weboldalakra és a telepített bővítményekre nincs hatással.
• Mielőtt a 7.2-re gondolnál, ellenőrizd a 7.1 hatásait, mert a blokkszintű responsive stílusok egy része !important jelzésű CSS-ként kerül az oldalra, a szerkesztő pedig minden bejegyzéstípusnál iframe-ben fut, ami régi metaboxos bővítményeknél és egyedi témáknál meglepetést okozhat.
• Egy átlagos céges honlapnál a józan út a december 8-a és 10-e közötti kiadás után egy tesztkörnyezetben elvégzett próba, majd mentéssel végzett frissítés, egy egyedi webshopnál viszont érdemes megvárni az első javítókiadást, hiszen a 7.1 után a 7.1.1 is négy héttel később érkezett.

Mikor jelenik meg a WordPress 7.2 és ki vezeti a kiadást?

A WordPress 7.2 első bétaverziója 2026. október 20-a és 22-e között, a végleges kiadás december 8-a és 10-e között várható. A kiadást Matt Mullenweg vezeti, a koordinációért David Baumwald felel, a technikai vezetők George Mamadashvili és Peter Wilson, a dátumok azonban a fejlesztés közben még módosulhatnak.

A menetrendet a Gutenberg Times szeptemberi hétvégi összefoglalója és a WordPress fejlesztői blogjának szeptemberi hírlevele egyaránt így közli, a kiadási csapatot pedig Jeffrey Paul jelentette be a Make WordPress Core oldalon 2026. szeptember 9-én. A csapat a 6.7-es verzió óta bevett, szándékosan kicsi és fókuszált felállást követi. Az új alapértelmezett téma dizájnját Henrique Iamarino irányítja, a fejlesztését Maggie Cabrera és Carolina Nymark vezeti, a beérkező hibajegyek rendezéséért (triage) Jb Audras és Eshaan Dabasiya felel, a tesztelést pedig Md Noruzzaman, Jina Parekh és Erick Wambua fogja össze.

Ha nem vagy WordPress-fejlesztő, a névsornál sokkal többet mond a menetrend, mert az egyben a te naptárad is. A WordPress kiadási gyakorlatában az első bétával lezárul az új funkciók köre, onnantól a fejlesztők már csak hibákat javítanak, a kiadásjelöltek (RC, release candidate) idején pedig lényegében csak a súlyos hibák javítása fér bele. A bővítmények és témák gazdái jellemzően ebben az ablakban tesztelik a saját termékeiket, vagyis ha egy általad használt bővítmény fejlesztője komolyan veszi a dolgát, a kompatibilitási frissítése novemberben vagy december elején érkezik. A kiadásjelöltek pontos dátumát az általunk átnézett források szeptember 22-én még nem rögzítették, ezért ezeket egyelőre csak ceruzával érdemes beírni a naptárba.

A decemberi időpont egy webshopnak különösen kényes, hiszen a 7.2 a karácsonyi szezon kellős közepén érkezik, alig másfél héttel a november 27-i Black Friday után. Tapasztalatunk szerint a legtöbb e-kereskedelmi hiba nem a frissítés napján derül ki, hanem akkor, amikor egy vásárló egy ritkábban használt fizetési módot vagy kuponkombinációt választ, ezért a főszezonban végzett főverzió-váltás a lehető legrosszabb időzítés. Egy webshopnál emiatt október végére érdemes kijelölni egy változáskezelési ablakot, amelyen kívül csak biztonsági frissítés kerülhet élesbe, a 7.2-re pedig ráér januárban átállni.

Milyen újdonságokat tervez a WordPress 7.2?

A WordPress 7.2 roadmapje, amelyet Anne McCarthy tett közzé 2026. szeptember 18-án, főleg a szerkesztő és az adminfelület finomítását, egy bővíthető webhelyszerkesztőt, űrlapelemek stílusozását, együttműködési funkciókat és biztonsági fejlesztéseket tervez. A core csapat kifejezetten jelzi, hogy nem minden tétel kerül be a decemberi kiadásba.

A roadmap elején álló figyelmeztetést érdemes szó szerint venni, saját fordításunkban így hangzik: „amit itt megosztunk, azon aktívan dolgoznak, de ez nem feltétlenül jelenti, hogy mindegyik bekerül a végleges kiadásba”. Az alábbi funkciók tehát szándékok, nem ígéretek, a menetrend és a tartalom pedig az október 20-a és 22-e közötti béta előtt még változhat. Ami a bétában benne van, annak jó esélye van decemberben is megjelenni, ami addig nem készül el, az jellemzően a következő főverzióra csúszik.

Dizájn és szerkesztő: űrlapelemek, örökölt stílusok, új állapotok

A marketingesek és a tartalomszerkesztők számára a legérdekesebb tétel az űrlapelemek stílusozása a Global Styles (globális stílusok) felületen. A roadmap szerint a gombok, a szöveges beviteli mezők, a legördülő listák és a címkék megjelenése egyedi CSS nélkül, egységesen állítható lesz, az előkészítés pedig már a Gutenberg 23.9-ben elkezdődött, ahol a label, a cite, a szöveges beviteli mező és a select elem stílusozhatóvá vált. Hogy ez egy külső űrlapbővítménnyel készült ajánlatkérő űrlapra mennyire hat, azt a bétában mindenképp próbáld ki, mert a bővítmények gyakran saját CSS-sel dolgoznak.

A második nagy terület a 7.1-ben bevezetett responsive stílusállapotok bővítése: több vezérlő kap képernyőméret szerinti beállítást, a harmadik féltől származó blokkok pedig nyilvános API-t kapnak ahhoz, hogy a saját egyedi vezérlőiket is responsive módon kezeljék. Érkezhet egy „-current” állapot a Navigation Link és a Tabs blokkhoz (vagyis külön stílus az éppen aktív menüpontnak vagy fülnek), a Navigation Link pedig szín-, keret- és térközbeállításokat kaphat.

Régóta hiányzó kényelmi funkció az örökölt stílusok megjelenítése: a blokk beállításainál látszani fog, milyen értéket örököl a globális stílusokból, a felülírásokat jelzés mutatja, egy visszaállító gomb pedig egy kattintással helyreállítja az alapértéket. A Gutenberg 23.8-ban megjelent pöttyjelzés a Global Styles felülírásainál ennek az első lépése volt. Ide tartozik még a hátterek, a méretek és a pozíció dizájneszközeinek bővítése, valamint egy hosszú lista apró szerkesztői bosszúságról (paper cuts) az írás, a kijelölés, a beillesztés, a fogd és vidd műveletek, valamint a mobilnézet területén.

Blokkok és API-k: leíró lista, ikonkeresés, Interactivity API

Új, szemantikus leíró lista (description list) blokk is szerepel a tervben három elemmel (core/description-list, core/description-term és core/description-detail). Ez a HTML régi dl, dt és dd elemeinek blokkos megfelelője, amely kiválóan illik termékjellemzőkhöz, szakszójegyzékhez vagy egy szolgáltatás paramétereinek felsorolásához, a szemantikus jelölést pedig a képernyőolvasók és a gépi feldolgozók is jobban értik, mint a bekezdésekből és félkövér címkékből összerakott rögtönzött listákat.

Az ikonblokk kulcsszavas keresést kap, így a menü ikont a „hamburger” szóval is megtalálod, a Table of Contents (tartalomjegyzék) blokk pedig szerveroldali, dinamikus renderelésre vált, hogy a szerkesztőben és az élő oldalon ugyanaz jelenjen meg. A fejlesztőknek szól az Interactivity API bővítése egy data-wp-html direktívával, amely reaktív HTML-tartalmat renderel, valamint egy routerrel, amely a kliensoldali navigációt figyeli. A React 19-re váltás szintén szerepel a listán, de a roadmap szerint nem valószínű, hogy teljesen elkészül a 7.2-re.

Együttműködés, média és admin

A 7.1-ben továbbfejlesztett Notes (jegyzetek) funkció a tervek szerint javaslati módot kap, amelyben a szerkesztő módosítást javasolhat, a szerző pedig elfogadhatja vagy elutasíthatja, érkezhetnek emoji-reakciók és egy külön eszköztár-gyorsbillentyű a jegyzeteléshez. A valós idejű, közös szerkesztést a csapat szándékosan kihagyta a 7.2 roadmapjéből, mert az ehhez szükséges architekturális döntések még nem születtek meg, a 7.1 field guide szerint pedig a funkciót már a 7.1 ciklusában tesztelték, de nem kapcsolták be.

A médiakezelésben újratervezett médiabeszúró jön a nagy képtárakhoz, a dinamikus galériák több forrásból dolgozhatnak, a statikus galériák rendezhetők lesznek, a médiaszerkesztő ablak pedig nyilvántartja, melyik kivágott kép melyik eredetiből készült. Az adminban átdolgozott, jobban diagnosztizálható hibaüzenetek jönnek másolás gombbal, az Omnibar (a parancspaletta) ikonjai SVG-re cserélődnek, a vezérlőpulton pedig egy „On This Day” widget hozhatja elő a régi tartalmakat. Teljesítmény terén a szkriptek és stílusok összefűzését (concatenation) előtöltés (prefetch) váltaná, a reszponzív képek támogatása pedig bővül.

Biztonság: alkalmazásjelszavak, Secrets API, sudo mód

A biztonsági tételek egy KKV-nak talán a legfontosabbak, még ha kevésbé látványosak is. Az alkalmazásjelszavak (application passwords, amelyekkel például egy automatizációs platform vagy egy mobilalkalmazás csatlakozik az oldalhoz) e-mailes értesítést kapnak, ha valaki újat hoz létre, emellett javul a HTTPS-környezet felismerése, biztonságosabbak lesznek az alapértelmezett szerepkörök és megjelenik a SameSite süti-attribútum támogatása. Egy ismeretlen, frissen létrehozott alkalmazásjelszó komoly figyelmeztető jel lehet, mert ezzel tartós hozzáférés szerezhető az oldalhoz, így ez az értesítés önmagában is sokat ér.

A Secrets API a roadmap szerint első osztályú, WP-CLI-ból is kezelhető tárolót adna a hitelesítő adatoknak, például az AI-szolgáltatások vagy a fizetési rendszerek API-kulcsainak, amelyeket ma sok bővítmény egyszerűen az adatbázis beállítástáblájában tart. A sudo mód azt jelenti, hogy a különösen érzékeny adminisztrátori műveletek előtt a WordPress újra bekéri a jelszót, ahogy azt a banki alkalmazásoknál vagy a GitHubon már megszoktuk. A HTML API fejlesztése a tartalomfeldolgozás biztonságát erősíti, ami a 7.1.1-ben javított XSS-hibák fényében különösen időszerű (a 7.1.1 részleteiről külön cikkben írtunk).

AI: MCP Adapter és WebMCP, de egyelőre bővítményben

A mesterséges intelligenciához kötődő munka a roadmap szerint az AI bővítményben folyik, arra pedig nincs garancia, hogy bármi bekerül belőle a core-ba. A tervek között szerepel a WordPress képességeinek (abilities) bővítése olvasási és írási műveletekkel, az MCP Adapter frissítése a legújabb specifikációhoz és közzététele a WordPress.org bővítménytárában, az MCP-hozzáférés az AI bővítmény felületén keresztül, a böngészőalapú WebMCP-ügynökfolyamatok vizsgálata, auditálható ügynökidentitások és delegálás, közös beágyazásalapú (embedding) szemantikus keresés, valamint streamingtámogatás a PHP AI Clientben.

A Gutenberg Times beszámolója szerint a WordPress Playground már most 16 műveletet tesz elérhetővé eszközként az AI-ügynököknek (webhelykezelés, PHP futtatása, navigáció, fájlok olvasása és írása), az MCP Adapter pedig beküldésre kész a bővítménytárba. Az MCP (Model Context Protocol) az a nyílt protokoll, amelyen keresztül egy AI-asszisztens szabványos módon ér el külső rendszereket, a WebMCP pedig a Google által javasolt webes szabvány, amellyel egy weboldal strukturált eszközöket kínálhat az ügynököknek (erről külön cikkben írunk részletesen). Egy magyar KKV-nak ebből decemberben még semmi sem lesz kötelező, de aki ügynökökkel szeretné kezeltetni a tartalmait, annak érdemes figyelnie az AI bővítmény fejlődését.

Az új alapértelmezett témáról annyi biztos, hogy külön dizájn- és fejlesztési vezetők dolgoznak rajta, a roadmap pedig szándékosan minimalista, több színváltozatot kínáló blogtémaként írja le, amely üres vászonként szolgál a testreszabáshoz. Egy céges honlapnak ez ritkán releváns, hiszen kevés vállalkozás használja az alapértelmezett témát élesben, a teszteléshez viszont hasznos, mert a hibák egy része csak akkor válik elkülöníthetővé, ha a saját témádat ideiglenesen egy alapértelmezettre cseréled.

Site Editor v2, DataViews és a nyilvános API-k: ez változik a fejlesztőknek

A Site Editor v2 a WordPress webhelyszerkesztőjének új, bővíthető alapokra épülő változata, amelybe a bővítmények saját képernyőket és beállításokat regisztrálhatnak. A DataViews az adminfelület React-alapú lista-, szűrő- és űrlapkomponens-családja, amelynek egyre több eleme válik nyilvános API-vá, ez pedig a fejlesztőknek új lehetőséget és új karbantartási feladatot jelent egyszerre.

Mi az a Site Editor v2?

A WordPress Developer Blog szeptemberi összefoglalója szerint a Gutenberg 23.9 nagyjából húsz pull requestet (kódmódosítási kérelmet) hozott a Site Editor v2 úgynevezett Boot csomagjához. Ezek az Identity nevű útvonaltól a témák előnézeti oldalán át (Global Styles-szerkesztéssel együtt) a regisztrált bővítmények felcsatolásáig, a vásznon belüli navigációig, a mentetlen változásokra figyelmeztető ablakig és a témakezelő képernyőkig terjednek. A funkció egyelőre kísérleti, az iránya viszont egyértelmű, mert a Gutenberg közreműködési irányelvei már előírják, hogy minden új webhelyszerkesztő-funkciónak a bővíthető szerkesztőbe is be kell kerülnie. A 7.2 roadmapje szerint a bővíthető alap a wordpress/boot útvonalkezelésre épül, harmadik féltől származó bővítmények saját képernyőket és beállításokat regisztrálhatnak benne, a navigáció szerkesztése pedig a webhelyszerkesztő oldalsávjába költözik.

Fejlesztőként ennek az a gyakorlati üzenete, hogy aki eddig DOM-manipulációval vagy nem dokumentált belső függvényekkel „ragasztott” saját panelt a webhelyszerkesztőbe, annak érdemes felkészülnie a hivatalos regisztrációs útra. Az ilyen megoldások minden Gutenberg-kiadásnál eltörhetnek, a bővíthető szerkesztő viszont éppen azt ígéri, hogy a saját képernyőd a WordPress frissítései után is a helyén marad.

DataViews és DataForm: az admin új építőkövei

A DataViews a WordPress adminfelületének újragondolt adatnézet-komponense, amely táblázatos, rácsos és listás megjelenítést, szűrést, rendezést és tömeges műveleteket ad, a DataForm pedig ugyanennek az űrlapos párja. A 7.1 field guide szerint a DataViews, a DataForm és a View Config API-k a nyári kiadásban értek be, a 7.1 kiadási közleménye pedig külön kiemeli a konfigurációs szűrőket. A szeptemberi fejlesztői hírlevél szerint további elemek váltak nyilvánossá: a Calendar és a RangeCalendar komponens a @wordpress/ui csomagba, a withIgnoreIMEEvents a @wordpress/keycodes csomagba került, a ValidatedInputControl pedig szintén nyilvános lett, a Gutenberg 23.8 ráadásul időmező-típust és -vezérlőt is adott a DataViewshoz.

A 7.2 roadmapje ennél is tovább megy: a nézet- és űrlapkonfigurációkat, a mezőket és a műveleteket szerveroldalon, PHP-ból is regisztrálni lehetne, ami azt jelenti, hogy egy PHP-ban otthonos bővítményfejlesztő React-tudás nélkül is bővíthetné az új adminnézeteket. Tegyük fel, hogy egy képzeletbeli balatoni panzió foglalási bővítménye ma egy saját, régi stílusú listatáblát használ: a DataViews-ra épülő változat szűrhető, rendezhető és a WordPress többi képernyőjével egységes lenne, a karbantartása pedig a core fejlődésével együtt haladna. A roadmapben szerepel még a hierarchia kezelésének és a tömeges műveletek felfedezhetőségének javítása, valamint egy DataForm-alapú oldalsáv a szerkesztőben, amely a mostani bejegyzésbeállítások helyére léphet.

PHP-only blokkok, billentyűparancsok és elavuló tulajdonságok

A Gutenberg 23.8 a block.json sémájába felvette az autoRegister jelzőt, amellyel a csak PHP-ban írt, szerveroldalon renderelt blokkok regisztrálhatók, a kódszerkesztők pedig automatikus kiegészítést és ellenőrzést adnak hozzá. Egy ügynökségnek ez azért jó hír, mert az egyszerű, dinamikus blokkokhoz (például egy nyitvatartás-kijelzőhöz vagy a legutóbbi referenciák listájához) nem kell JavaScript-buildláncot fenntartani. A Gutenberg 23.9 deklarálható billentyűparancs-API-t hozott a blokkváltozatokhoz és -átalakításokhoz (a változatoknál egy shortcut objektummal, az átalakításoknál egy shortcuts tömbbel), az új @wordpress/kebab-case csomag pedig a PHP _wp_to_kebab_case() függvényével azonos módon, a számokat is ugyanúgy kezelve alakítja át a neveket, ami csökkenti az eltérést a JavaScriptben és a PHP-ban előállított osztály- és változónevek között.

Van egy elavulás is, amelyre a saját blokkjaidban figyelned kell. Az InnerBlocks komponens template és templateInsertUpdatesSelection tulajdonsága elavult, ezeket a blokk beállításai közé kell áthelyezni, a WordPress Developer Blog szerint pedig nagyjából húsz core blokk már átállt. A régi tulajdonságok egyelőre működnek, ezért nem kell pánikba esni, de a tesztkörnyezetben nézd meg a böngésző fejlesztői konzolján megjelenő elavulási figyelmeztetéseket, mert ezekből derül ki a legolcsóbban, mit kell átírni a következő kiadások előtt.

Milyen PHP- és Node.js-verzió kell a WordPress 7.2-höz?

Az éles szerveren a WordPress 7.2-nél várhatóan továbbra is a PHP 7.4.0 a minimum és a PHP 8.3 az ajánlott változat, mert az általunk átnézett 7.2-es anyagok nem említenek emelést. A Node.js 24.18.0 és az npm 11.16.0 2026. szeptember 8-tól csak a WordPress fejlesztői build-eszközeihez kell, a futó weboldalhoz nem.

PHP: a minimum 7.4, a józan cél legalább 8.3

A WordPress 7.0 megjelenésével megszűnt a PHP 7.2 és 7.3 támogatása. John Blackbourn 2026. január 9-i közleménye szerint az új minimum a PHP 7.4.0, az ajánlott változat pedig a PHP 8.3, a PHP 7.2-t vagy 7.3-at futtató oldalak a 6.9-es ágon maradnak, amelyre a biztonsági javításokat csak gesztusként, a lehetőségekhez mérten portolják vissza. A közlemény idején a WordPress-oldalak 22,20%-a még PHP 7.4-en futott, 5,69%-uk PHP 8.0-n, 15,39%-uk 8.1-en, 27,29%-uk 8.2-n és 16,74%-uk 8.3-on. A core csapat azt is rögzítette, hogy nincs terv a minimális PHP-verzió menetrend szerinti emelésére, a döntésnél pedig továbbra is az 5%-os használati küszöb számít, így a PHP 7.4 22%-os aránya mellett a közeli minimumemelés nem valószínű.

Ettől még nem érdemes PHP 7.4-en maradni. A PHP projekt a 7.4-es és a 8.0-s ágat már évekkel ezelőtt kivezette, a 8.1 biztonsági támogatása 2025 végén ért véget, a 8.2-é pedig 2026. december 31-én jár le, vagyis nagyjából három héttel a WordPress 7.2 után. A WooCommerce-t használó boltoknak ez különösen sürgős, mert a WooCommerce a 11.5-ös verziótól, 2027 januárjától már nem támogatja a PHP 7.4-et és a 8.0-t (erről külön cikkben írunk részletesen). A PHP-verziót a vezérlőpult Eszközök menüjében található Site Health (webhelyállapot) oldal információs fülén találod, a váltást pedig a legtöbb tárhelyszolgáltatónál a tárhely kezelőfelületén lehet elvégezni, előtte viszont mindig egy tesztkörnyezetben próbáld ki.

Node.js 24 és npm 11: kit érint valójában?

Manzoor Wani 2026. szeptember 9-i közleménye szerint szeptember 8-tól a wordpress-develop és a Gutenberg tároló trunk ága, valamint mindkét tároló 7.1-es ága Node.js 24.18.0-t és npm 11.16.0-t kér, a régebbi ágakon viszont marad a Node.js 20.10.0 és az npm 10.2.3 mint minimum. Az indoklás szerint a Node.js 20-as ága 2026 áprilisában elérte az életciklusa végét, a csomagok és az ökoszisztémák elkezdték elhagyni a támogatását, a GitHub pedig kivette a Node.js 20-at az Actions futtatókörnyezeteinek lemezképeiből. A váltás a közlemény szerint egy régóta várakozó eszköz- és biztonsági munkasort is megnyit, köztük egy hat éve visszatérő hibatípus megszüntetését, amikor valami a monorepóban működött, a közzétett @wordpress csomagokat használó fejlesztőknél viszont eltört.

A közlemény egyértelműen kimondja, hogy a változás csak a WordPress fejlesztésének build-eszközeit érinti, az éles oldalakat és a bővítményeket nem, vagyis egy céges honlap tulajdonosának ezzel nincs teendője. Annak viszont van, aki saját témát vagy bővítményt fejleszt @wordpress csomagokra épülő build-folyamattal. A közreműködőknek a közlemény a Node.js frissítését, az nvm install és nvm use parancsokat (vagy az fnm hasonló megfelelőjét), a függőségek npm ci paranccsal történő újratelepítését és a nyitott pull requestek friss trunkra alapozását javasolja, mert a kötelező ellenőrzések már Node.js 24-en futnak. A saját projektjeidben is érdemes átnézni a CI-folyamatokat (ha egy GitHub Actions workflow még Node.js 20-at kér, az előbb-utóbb el fog törni), a @wordpress csomagok frissítése előtt pedig nézd meg a package.json engines mezőjét, mert abból derül ki, melyik Node.js-verzióval számol a csomag.

Mit tesztelj a 7.1 responsive stílusai és az ikonregisztráció után?

A 7.1 után elsősorban azt nézd meg, hogy a mobil- és tabletnézetre megadott blokkstílusok nem ütköznek-e a téma saját CSS-ével, hogy a régi metaboxos bővítmények működnek-e az iframe-be zárt szerkesztőben, illetve hogy az egyedi ikonok és gombállapotok a 7.2 bétájában is ugyanúgy jelennek-e meg.

Responsive stílusok: hol ütközhetnek a téma CSS-ével?

Isabel Brison 2026. augusztus 5-i fejlesztői jegyzete szerint a WordPress 7.1 óta tablet- és mobilnézetre külön stílus adható meg, a globális stílusokban blokktípusonként, a blokk beállításainál pedig egyedi blokkpéldányonként. Két beépített töréspont van: a mobil a legfeljebb 480 pixel széles, a tablet a 480 és 782 pixel közötti képernyőkre vonatkozik, az alapstílus pedig az asztali nézet, amely minden méretre érvényes, ha nincs felülírva. A blokktémák a theme.json settings.viewport kulcsában saját töréspontokat adhatnak meg px, em vagy rem mértékegységben, a responsive értékek pedig a tipográfia, a szín, a háttér, a keret, a méretek, a térköz és az elrendezés alapbeállításainál működnek.

A kockázat a részletekben van. A WordPress médialekérdezésekhez kötött CSS-t és egy stabil, generált osztálynevet ad a blokkoknak, az egyes blokkpéldányokra megadott, nem elrendezési állapotdeklarációkat pedig !important jelzéssel látja el, hogy felülírhassák a blokk alapértelmezett, soron belüli stílusait. Ha tehát például a téma saját CSS-e 768 pixelnél vált tabletnézetre, a WordPress pedig 782-nél, akkor a kettő között egy keskeny sávban két különböző szabály érvényesül, egy !important jelzésű blokkstílust pedig a téma CSS-e már nehezen ír felül. Ügynökségi oldalon hasznos tudni, hogy a responsiveEditingEnabled szerkesztőbeállítás false értékével a responsive felület elrejthető (a meglévő responsive stílusok ettől még működnek), a Gutenberg 23.8 pedig a blockStatesEditingEnabled beállítással az állapotvezérlők kikapcsolását is lehetővé tette, ami egy túl sok szabadságot kapott ügyféloldali szerkesztőnél kifejezetten hasznos.

Gombállapotok, ikonok és az iframe-be zárt szerkesztő

A 7.1 „Mary Lou” kiadási közleménye szerint a gomboknál külön stílus adható a rámutatás (hover), a fókusz (focus) és a lenyomás (active) állapotára, a 7.2 pedig további egyéni állapotokat hozhat. Ezeknél elsősorban a billentyűzetes fókusz láthatóságát ellenőrizd, mert egy túl finomra hangolt hover-stílus könnyen eltünteti a fókuszkeretet, ami akadálymentességi hiba. Az új, nyilvános SVG Icon API (például a wp_register_icon_collection() függvénnyel) szabványos módot ad egyedi ikonok regisztrálására és megjelenítésére, a Gutenberg Times szerint pedig a következő lépés az lesz, hogy a block.json ikonregisztrációja is WordPress-ikonokat használhasson. Ha a témád saját ikonkészletet vagy SVG-sprite-ot használ, nézd meg, nem jelenik-e meg duplán vagy hibás méretben egy ikon, ha pedig már átálltál az új API-ra, ellenőrizd az ikonokat a szerkesztőben és az élő oldalon is.

A 7.1 field guide szerint a szerkesztő minden bejegyzéstípusnál iframe-ben fut, a régi metaboxokat használó képernyőkön is. Ez a lépés, amely a szerkesztett tartalmat elszigeteli az adminfelület stílusaitól, régóta napirenden volt, de a régi, a szerkesztő dokumentumába közvetlenül szkriptet vagy stílust injektáló bővítményeknél és egyedi mezős megoldásoknál hibát okozhat. A 7.1-ben érkezett még a böngészőben végzett képtömörítés és -átméretezés, az AVIF, a HEIC és a HDR gain map formátumok natív támogatása, a médiatár végtelen görgetése (felhasználónként kikapcsolható) és az admin sáv, amely minden szerkesztőben látható marad.

Oldaltulajdonosi szemmel: ennyi látszik a WordPress 7.2-ből egy céges oldalon

Hogy a WordPress 7.2-ből mennyi látszik a saját oldaladon, az elsősorban a témádon múlik. Egy blokktémás, a webhelyszerkesztővel összerakott honlapon a decemberi kiadás dizájnújdonságai (űrlapstílusok, örökölt stílusok, bővebb responsive beállítások) közvetlenül megjelennek, egy klasszikus témára épülő, oldalépítő bővítménnyel szerkesztett oldalon viszont ezek nagy része rejtve marad, mert az oldalépítő saját felülete jórészt független a blokkszerkesztőtől. A biztonsági, médiakezelési és adminfejlesztések ellenben mindenkit érintenek.

Vegyünk egy képzeletbeli, 12 fős kecskeméti asztalosüzemet, amelynek referenciaoldala oldalépítős klasszikus témán fut, a blogját pedig a marketinges írja és az ügyvezető hagyja jóvá. Ha a blogbejegyzéseket a blokkszerkesztőben írják, nekik a 7.2-ből leginkább a Notes javaslati módja lehet hasznos, amely kiválthatja az e-mailben ide-oda küldözgetett Word-változatokat, valamint az alkalmazásjelszavakról érkező e-mailes értesítés, ha az oldalhoz egy automatizációs eszköz is csatlakozik. Egy képzeletbeli debreceni webshopnál viszont a legfontosabb kérdés az, hogy a WooCommerce és a fizetési bővítmények mikor adnak ki a 7.2-vel tesztelt verziót, mert amíg ez nincs meg, a főverzió-váltás felesleges kockázat.

Egy ügyvédi iroda vagy könyvelőiroda egyszerű bemutatkozó oldalán a 7.2 decemberben jó eséllyel néhány perces, eseménytelen frissítés lesz. Ott a legnagyobb kockázatot nem a WordPress, hanem az évek óta nem frissített bővítmények és a régi PHP-verzió jelentik, ezért náluk a felkészülés lényege a PHP 8.3-ra váltás és a bővítménylista megtisztítása, nem a 7.2 funkcióinak tanulmányozása.

Hogyan teszteld a WordPress 7.2 bétát az éles oldal kockáztatása nélkül?

A WordPress 7.2 bétáját soha ne telepítsd élesre: használd a tárhelyszolgáltató tesztkörnyezetét (staging), egy helyi fejlesztői környezetet vagy a böngészőben futó WordPress Playgroundot. A tesztpéldányt a WordPress Beta Tester bővítménnyel állíthatod a béta csatornára, majd a legfontosabb oldalakat, űrlapokat és a vásárlási folyamatot próbáld végig.

A WordPress Playground a WordPress hivatalos, böngészőben futó változata, amely telepítés nélkül, néhány másodperc alatt ad egy eldobható oldalt, így egy bővítmény vagy egy blokk gyors kipróbálására ideális. Egy teljes céges oldal tesztjére viszont a tárhely saját staging funkciója vagy egy helyi másolat a jobb választás, mert ott a valódi adatbázissal, a valódi bővítményekkel és a valódi tartalommal dolgozol.

• Készíts friss másolatot az éles oldalról. A tesztkörnyezet a mai állapotot tükrözze, különben olyan hibát keresel, amely élesben már nincs is meg, vagy éppen elsiklasz egy új felett.
• Kapcsold ki a kimenő leveleket és a fizetést a másolaton. Egy tesztkörnyezetből kiküldött rendelésvisszaigazolás vagy hírlevél kínosabb bármelyik szoftverhibánál, ezért a fizetési kaput állítsd teszt módba.
• Állítsd a másolatot a béta csatornára. A WordPress Beta Tester bővítménnyel október 20-a és 22-e között telepítheted a WordPress 7.2 első bétáját, majd minden újabb béta és kiadásjelölt megjelenésekor frissíts.
• Járd végig a kritikus útvonalakat. Kezdőlap, fő szolgáltatásoldalak, ajánlatkérő űrlap, keresés, kosár és fizetés, a szerkesztőben pedig egy új bejegyzés létrehozása képpel, galériával és egyedi blokkokkal.
• Jegyezd fel és jelentsd a hibákat. Ha egy bővítmény hibázik, írj a fejlesztőjének a WordPress.org támogatási fórumán, ha pedig maga a WordPress, a jelzéseddel a core tesztcsapatának munkáját is segíted.

Felkészülési terv lépésről lépésre októbertől decemberig

A WordPress 7.2-re való felkészülés tíz lépésben elvégezhető, a munka nagy része pedig már október 20-a előtt elkezdhető. Az alábbi sorrend egy átlagos, 5 és 50 fő közötti cég honlapjára vagy webshopjára készült, az időpontok pedig a jelenlegi menetrendhez igazodnak.

• Még szeptemberben telepítsd a 7.1.1-et. A 2026. szeptember 17-i biztonsági kiadás tizenegy sérülékenységet javít, ez független a 7.2-től és nem várhat.
• Készíts leltárt. Írd fel a WordPress- és a PHP-verziót, a téma típusát (blokktéma, klasszikus, gyermektéma vagy egyedi fejlesztés) és a bővítmények listáját az utolsó frissítésük dátumával.
• Selejtezd a bővítményeket. Ami egy éve nem frissült vagy már nem használod, azt távolítsd el, mert minden felesleges bővítmény plusz kockázat a főverzió-váltásnál.
• Válts PHP 8.3-ra. A váltást először a tesztkörnyezetben, utána élesben végezd el, legkésőbb november végéig, hogy a WordPress-frissítéssel ne egyszerre változzon két dolog.
• Rendezd a mentést és a tesztkörnyezetet. Legyen napi automatikus mentés, a visszaállítást pedig legalább egyszer próbáld is ki, mert a ki nem próbált mentés csak remény.
• Futtasd le a 7.1-es ellenőrzőlistát. A responsive stílusok, a gombállapotok, az ikonok és a metaboxos bővítmények tesztje most még nyugodt tempóban elvégezhető.
• Frissítsd a fejlesztői környezetet. Aki saját témát vagy bővítményt fejleszt, álljon át a Node.js 24.18.0-ra és az npm 11.16.0-ra, frissítse a CI-folyamatokat, a saját blokkokban pedig írja át az elavult InnerBlocks-tulajdonságokat.
• Teszteld a bétát október 20-a után. A kritikus útvonalakat minden újabb béta és kiadásjelölt után fusd végig újra, a talált hibákat pedig jelezd a bővítmények fejlesztőinek.
• Rögzítsd a frissítés időpontját. Egyszerű oldalnál a kiadást követő egy-két hét, webshopnál a karácsonyi szezon utáni január a jó választás, az időpontot pedig felelőssel együtt írd be a naptárba.
• Frissíts mentéssel, majd figyelj. A frissítés után ellenőrizd a fő oldalakat, az űrlapokat és a naplókat, a következő napokban pedig figyeld a hibaüzeneteket és a javítókiadást.

Azonnal frissíts decemberben vagy várj a javítókiadásra?

Egyszerű, kevés bővítménnyel működő céges oldalon a WordPress 7.2 a kiadás után egy-két héten belül, tesztkörnyezetben elvégzett próba után nyugodtan telepíthető. Egyedi témánál, sok bővítménynél vagy webshopnál érdemes megvárni a bővítmények kompatibilitási frissítéseit és az első javítókiadást, a biztonsági kiadásokat viszont mindig azonnal telepítsd.

A különbségtétel oka egyszerű: a főverzió új funkciókat és új kódot hoz, a javítókiadás viszont a már ismert hibákat zárja be. A 7.1 augusztus 19-én jelent meg, a 7.1.1 pedig szeptember 17-én, vagyis négy héttel később érkezett tizenegy biztonsági javítással, valamint 17 core- és 19 blokkszerkesztő-hibajavítással. Aki tehát nem sietett a főverzióval, az egy stabilabb állapotra frissített, a biztonsági javításokat pedig a korábbi ágakra visszaportolt kiadásokban is megkapta. Nézd meg a Frissítések oldalon azt is, be van-e kapcsolva a főverziók automatikus telepítése, mert ha igen, a 7.2 decemberben magától is megérkezhet, ami egy webshopnál nem feltétlenül kívánatos.

Mennyi időbe és pénzbe kerül a felkészülés egy KKV-nak?

Saját becslésünk szerint egy egyszerű céges oldal felkészítése a WordPress 7.2-re 2 és 4 fejlesztői óra, egy egyedi témás oldalé 6 és 10 óra, egy egyedi fejlesztésű webshopé 12 és 20 óra között van. Feltételezett 12 000 Ft-os óradíjjal ez nagyjából 24 000 és 240 000 Ft közötti összeg.

A becslés az általunk jellemzőnek tartott feladatokra épül: leltár, PHP-váltás tesztkörnyezetben, a 7.1-es ellenőrzőlista, a béta és a kiadásjelölt tesztje, végül a mentéssel végzett éles frissítés. A számítás menete egyszerű: 2 és 4 óra szorozva 12 000 Ft-tal 24 000 és 48 000 Ft, 6 és 10 óra 72 000 és 120 000 Ft, 12 és 20 óra pedig 144 000 és 240 000 Ft. Az óradíj szemléltető feltételezés, a te fejlesztőd díja ettől eltérhet.

Az összeget érdemes a kiesés költségéhez mérni. Tegyük fel, hogy a korábban említett képzeletbeli debreceni webshop decemberben napi 400 000 Ft bruttó forgalmat bonyolít, ekkor egyetlen napnyi leállás vagy hibás pénztár nagyobb bevételkiesést jelent, mint a teljes felkészülés a felső becsléssel számolva. A felkészülés költsége ráadásul nem vész el a 7.2-vel, hiszen a rendbe tett tesztkörnyezet, a megtisztított bővítménylista és a friss PHP a következő főverziónál is megtérül.

Miben segít a Convergo?

Ha nem szeretnéd a karácsonyi szezonban kitalálni, mi romlott el egy frissítés után, a Convergo support, üzemeltetés és tárhely szolgáltatása átveszi a WordPress-frissítések tesztelését és élesítését: a Support csomag havi 30 000 Ft-ért három fejlesztői órát tartalmaz, ami egy egyszerű oldal 7.2-es felkészítésének nagy részét lefedheti. Egyedi témánál vagy saját blokkoknál programozás és egyedi fejlesztés keretében, 10 000 Ft-os óradíjjal átírjuk az elavult részeket és frissítjük a build-folyamatot. Ha előbb azt szeretnéd tudni, hol áll az oldalad, egy IT audit és digitális tanácsadás megmutatja a PHP-, bővítmény- és mentési kockázatokat. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük a leltárt és a menetrendet.