WordPress: 2026-ban visszatérhet a három nagyverziós kiadási ritmus, már formálódik a 7.0 terve

A WordPress fejlesztési ritmusát évek óta érdemes fél szemmel figyelni, mert közvetlenül hat arra, hogy mikor és milyen kockázattal vezetsz be új core-funkciókat, mikor érdemes kompatibilitást tesztelni, és hogyan tervezel hosszabb távon PHP-verziót, bővítmény API-kat vagy akár admin felületi változásokat.

A legutóbbi, negyedéves Core Committers Check-in alapján (ahol core committers és a projektvezetés egyeztet) 2026-ban a WordPress visszatérhet a három nagy (major) kiadásos ütemezéshez. Ugyanezen a megbeszélésen már a WordPress 7.0 korai tervezése is napirenden volt: szóba került több, 6.9-re eredetileg tervezett funkció, az admin redesign iránya, az AI-s alapok (WordPress AI Client), illetve a minimum támogatott PHP-verzió emelésének kérdése.

Mi változott a korábbi tervekhez képest? (és miért érdekes ez 2026-ra)?

Az idei év elején még az a kommunikáció ment, hogy 2026-ban csak egy major kiadás várható. Ennek okaként „folyamatban lévő jogi ügyeket” említettek (a hivatkozások alapján ez a WP Engine peres helyzetére utal), valamint azt a környezetet, hogy az Automattic a WordPress-hozzájárulásait is visszafogta.

Ehhez képest a mostani committers egyeztetés alapján a szándék már az, hogy 2026-ban újra három nagy verzió legyen. Ez fejlesztői oldalról azért nagy dolog, mert teljesen más terhelést és tervezést jelent: több release squad ciklus, több beta/RC fázis, gyakoribb „feature freeze” időszak, és több pont, ahol a plugin/theme kompatibilitást elő kell venni.

Három major kiadás 2026-ban: mit lehet tudni a 7.0 időzítéséről?

A Make WordPress Core-on közzétett jegyzet szerint a „szándék” az, hogy 2026-ban újra beálljon a három kiadásos kadencia, és a WordPress 7.0 célzottan márciusra vagy áprilisra essen.

A februári megjelenést kifejezetten kizárták. Ennek praktikus oka van: egy februári release esetén a Beta 1 nagyon korán, január elejére esne, amikor sok közreműködő még szabadságon van, és több folyamatban lévő funkció sem lenne kész időben.

Flagship eseményekhez időzített kiadások? Még csak ötlet szinten

Felmerült az is, hogy a jövőbeni major kiadások igazodhatnának „zászlóshajó” eseményekhez – hasonlóan ahhoz, hogy a WordPress 6.9 a State of the Word idejére lett időzítve. Ugyanakkor a jegyzet alapján ezt jelenleg inkább lehetőségként, nem pedig kész tervként kezelik.

A fő ellenérv az extra komplexitás: utazások, időzónák, valamint a release squad és a közreműködők elérhetősége nehezebben tervezhető, ha az egész kiadási folyamatot egy személyes esemény köré kell szervezni. Az ötletet „további egyeztetésre” jelölték meg.

WordPress 7.0: milyen funkciók kerülhetnek képbe?

A megbeszélésen több olyan elem is előkerült, ami eredetileg a WordPress 6.9 scope-jában szerepelt, és most potenciális jelöltként merült fel a 7.0-hoz.

• Template activation (sablon aktiválás) mint lehetséges 7.0-s célpont.
• A Tabs block (fülek blokk) mint jelölt funkció.
• Az Abilities API (képességek API) kapcsán kliensoldali képességek (client-side abilities).
• Kliensoldali médiavágás/-szerkesztés (client-side media editing) ötlete is felmerült.

A legnagyobb figyelmet viszont egyértelműen az AI-s alapozás kapta, azon belül is a WordPress AI Client.

WordPress AI Client: mi ez, és miért merült fel, hogy core-ba kerüljön?

A WordPress AI Client az AI Team által meghatározott négy „Building Blocks” (alap építőkocka) egyike, és most már konkrétan napirenden van, hogy core része legyen-e.

A jegyzet szerint a WordPress AI Client 0.1.0 verziója nemrég megjelent. A célja, hogy a bővítmények és sablonok natív, provider-agnostic módon tudjanak AI szolgáltatásokhoz kapcsolódni. A provider-agnostic itt azt jelenti, hogy nem egyetlen szolgáltatóra (vagy modellre) van kihegyezve a megoldás, és nem kényszeríti rá az ökoszisztémára, hogy mindenki ugyanazt a harmadik felet használja.

A megközelítés lényege, hogy a WordPress AI Client a PHP AI Client koncepcióját és kódalapját a WordPress ökoszisztémához igazítja, WordPress-es konvenciókkal és integrációs pontokkal.

Konkrét technikai alapok, amiket már most tud

• A WordPress HTTP API-t használja a kérésekhez, vagyis nem hoz be saját „külön HTTP stacket”.
• Az API kulcsokat központosítva kezeli egy „AI Credentials” (AI hitelesítő adatok) képernyőn.
• Támogatja a modellválasztást úgy, hogy a bővítményeknek ne kelljen beégetniük egy konkrét provider nevét (hard-code) a saját kódjukba.

A következő lépések (a tervek szerint)

• Abilities API támogatás hozzáadása.
• REST endpointok (REST végpontok) bevezetése az AI Client köré.
• Egy kliensoldali Prompt Builder (prompt-összeállító) hozzáadása.

A committers oldaláról az a fő érv a core-ba emelés mellett, hogy ez az alapréteg ösztönözné az ökoszisztémát, hogy stabil, közösen használt fundamentumokra építsen (külön kiemelve az Abilities API-t). A meeting jegyzet ezt úgy fogalmazza meg, hogy az egymáshoz kapcsolódó API-k összekötése rengeteg új lehetőséget nyitna fejlesztőknek és site owner-eknek.

Fontos korlátok: WordPressnek „agnosztikusnak” kell maradnia

A jegyzet külön hangsúlyozza, hogy a WordPress mindig agnosztikus marad: nem fenntartható, ha a core egy konkrét AI modellt szállít, vagy ha csak néhány harmadik fél szolgáltatásával integrálódik. Ez technikai és ökoszisztéma-szinten is zsákutca lenne.

Szóba kerültek hosszabb távú lehetőségek is, például a gépi (machine-based) vagy böngészőszintű modellek megjelenése, de a leírtak alapján itt nem választottak irányt – inkább csak megemlített, későbbi opcióként kezelték.

Mire használná egy „alap WordPress” az AI-t? Use case-eket kérnek, mielőtt döntés születik

Mielőtt bármilyen core-döntés születne az AI Client kapcsán, a közreműködők szeretnének tiszta, kézzelfogható use case-eket látni a „default WordPress” világában. A jegyzet példákat is hoz:

• A Médiatárban (Media Library) keresés tárgy/tematika alapján (pl. „kép, amin bicikli van”).
• Hírlevelek generálása a friss tartalmak alapján (recent content alapú newsletter készítés).

Admin redesign: nem teljes újratervezés, inkább egy átfogó ráncfelvarrás

Az admin felület modernizálása szintén előkerült. A mostani állás szerint a cél nem egy mindent felforgató új admin, hanem inkább egy „fresh coat of paint” megközelítés: azaz a meglévő admin felület vizuális és UX frissítése, annak újrahangolása, ami már ott van.

Ez azért érdekes, mert korábban – például a júliusi negyedéves egyeztetésen – felmerült, hogy a redesign inkább kísérleti jelleggel jelenjen meg a Gutenberg bővítményben, vagy akár külön „MP7” bővítményként. Az MP7 elnevezés egy történelmi utalás: az MP6 volt az a 2013-as „feature as a plugin” kezdeményezés, ami végül a WordPress 3.8 admin redesignját alapozta meg.

Az admin redesign a Gutenberg roadmap Phase 3: Collaboration szakaszának része. A munka ezen a fronton 2023-ban kapott erősebb nyilvánosságot, amikor Matías Ventura (Gutenberg Lead Architect) közzétette a modern admin élményről szóló vízióját, majd a 2023-as State of the Word során új layoutokat is bemutatott.

Fontos fejlemény, hogy volt olyan terv, amely szerint a redesign egy korai előnézete a WordPress 6.9-cel együtt érkezett volna, ezt azonban szeptemberben elengedték: az akkor frissített roadmap már azt jelezte, hogy a jelenlegi állapot alapján „már nem tervezett”.

Minimum PHP verzió: miért merült fel a 7.4, és mi a tét?

A megbeszélésen külön blokkot kapott a minimum támogatott PHP verzió emelése, konkrétan az, hogy van-e elég „meggyőző ok” ahhoz, hogy a projekt a minimumot PHP 7.4-re húzza fel.

Az érvelés a gyakorlatból indult: a régi PHP verziók támogatása folyamatos kompatibilitási terhet jelent, ami kódfelduzzadást okoz és lassítja a fejlesztést. A PHP 7.4 irányába lépés közelebb vinné a kódbázist a következetesebb típusossághoz (consistent typing), és a jegyzet szerint ez nem csak a fejlesztőknek teszi könnyebbé a kód megértését, hanem még az AI rendszereknek is.

További, nagyon pragmatikus szempont: több harmadik féltől származó AI SDK eleve későbbi PHP verziókat igényel, és ha a minimum túl alacsony, az egyszerűen elzárja a WordPress-t attól, hogy ezeket ésszerűen használni lehessen.

A téma végig úgy volt keretezve, hogy a haladás és a felhasználói bázis megtartása között kell egyensúlyozni, vagyis nem cél „hátrahagyni” senkit. A megbeszélésen nem született döntés.

Mi lesz a következő lépés? Nyitottabb meetingek, 2026-os menetrend, 7.0/7.1 scope

A publikált jegyzet alapján Jonathan Desrosiers több konkrét follow-up pontot is felsorolt a megbeszélés végén. Ezek jól mutatják, hogy a 2026-os váltás nem csak egy mondat a levegőben, hanem szervezési és tervezési feladatok sorozata:

• Javaslat nyitottabb és félig nyitott meeting formátumokra.
• A 2026-os release schedule publikálása.
• A 7.0 célzott funkcióinak megerősítése, és akár a 7.1 célok előzetes tisztázása is.
• Annak felmérése, hogy a major kiadások személyes eseményekhez igazítása mennyire reális a gyakorlatban.

Összefoglalás: mire érdemes készülni fejlesztőként?

A mostani committers egyeztetésből három, fejlesztői szempontból nagyon is kézzelfogható irány látszik: (1) 2026-ban reális a gyakoribb major kiadás, (2) a 7.0 körül egyre komolyabban vizsgálják az AI-s alapréteget (WordPress AI Client) úgy, hogy közben a WordPress agnosztikus maradjon, és (3) napirenden van az admin felület frissítése és a PHP minimum emelésének kérdése is. Ezek együtt azt jelentik, hogy a következő évben a kompatibilitás, a release-ciklusokra való felkészülés és az AI-integrációs alapok figyelése stratégiai kérdés lesz sok plugin- és ügynökségi csapatnál.