A WordPress 7.0 2026. május 20-án jelent meg Armstrong kiadásnéven, hat héttel később, mint az eredeti 2026-os ütemterv dátuma, és ez a legnagyobb következményekkel járó core kiadás az ügynökségek számára a block editor óta. A főcím az, hogy a core mostantól tud beszélni a generatív MI-modellekkel. A fontosabb részlet az, hogy a core azt is meghatározza, hogyan beszéljen velük egy bővítmény, és ez csendben átírja, mit feltételezhet minden bővítmény a saját területéről.

A szerkesztők számára a látható változások szerények: van egy Command Palette, egy rendezettebb vezérlőpult, egy betűkészlet-kezelő képernyő és jobb változatkezelés. Aki hivatásszerűen üzemeltet webhelyeket, annak a lényeg az adminfelület alatt van: hitelesítő adatok tárolója az options táblában, egy nyilvántartás arról, mire képes a webhely, és egy REST felület, amely ezt felsorolja. Ebből semmi sem opcionális, mert a core-ral érkezik, nem egy bővítménnyel, amelyet valaki kiválasztott.

Ez a gyakorlati olvasat. Mi került be ténylegesen, mit húztak ki tizenkét nappal a kiadás előtt és miért, mit tör el a frissítés és mit nem, és mit mondjon annak az ügyfélnek, aki épp most olvasott egy főcímet a WordPressbe kerülő MI-ről.

Érdemes frissíteni? Igen, de menjen el a 7.1 verzióig, ne álljon meg a 7.0 kiadásnál. A WordPress 7.1 2026. augusztus 19-én jelent meg, a 7.0 mögött pedig négy karbantartási kiadás áll. Az MI-funkciók tétlenek maradnak, amíg egy adminisztrátor el nem ment egy szolgáltatói kulcsot a Beállítások, majd Connectors képernyőn, így a frissítés önmagában semmit sem küld el a tartalmából. Az igazi kockázat itt a bővítmények és sablonok szokásos kompatibilitása, nem az MI.

Mi került be valójában a WordPress 7.0 kiadásba

A kiadás Louis Armstrong nevét viseli, követve a projekt szokását, hogy a főverziókat dzsesszzenészekről nevezi el. A kiadási bejelentés több mint 875 közreműködőt, valamint több mint 420 fejlesztést és javítást tulajdonít a verziónak.

A bekerült elemek listája elég rövid ahhoz, hogy hasznos legyen. A core kapott egy AI Client komponenst, egy szolgáltatófüggetlen PHP felületet promptok generatív modellekhez küldésére. Kapott egy Connectors képernyőt a Beállítások alatt, ahol egy adminisztrátor tárolja a szolgáltatói hitelesítő adatokat. Megkapta az Abilities API JavaScript felét, amelynek PHP fele már a 6.9 kiadásban megjelent.

A szerkesztői oldalon van egy Command Palette a Ctrl+K vagy Cmd+K billentyűkkel, egy megújított vezérlőpult, külön betűkészlet-kezelő oldal, a változatok vizuális átpörgetése, valamint új Heading, Breadcrumbs és Icons blokkok, mellettük pedig lightbox diavetítés a galériákhoz.

Ami nem került be, az éppen az a funkció volt, amely köré az egész kiadást építették. A valós idejű együttműködő szerkesztést tizenkét nappal az indulás előtt eltávolították. Ez a hiány és a mögötte álló ok többet mond a core jelenlegi állapotáról, mint a funkciólista.

Miért csúszott a dátum

A kiadást eredetileg 2026. április 9-re tervezték. Május 20-ra csúszott, mert az együttműködő szerkesztés nem volt kész, és a projekt nem akarta abban az állapotban kiadni. A további útról szóló bejegyzés kifejezetten leírja, hogy a csúszás azért volt, hogy több idő jusson a valós idejű együttműködés megvalósításáról érkező tesztvisszajelzések kezelésére, a ciklus pedig visszatért bétába, miközben technikai okokból megtartotta a release candidate verziószámokat.

Ez szokatlan. Egy főverzió, amely az RC után visszalép bétába, erős jelzés, és ez volt a helyes döntés.

Az AI Client: a core az absztrakciót adja, nem a modellt

A WordPress 7.0 legfontosabb architekturális ténye az, hogy a core nem tartalmaz MI-modellt, API-kulcsot, sem kapcsolatot bármelyik szolgáltatóval. Az AI Client fejlesztői jegyzete világosan kimondja, hogy a WordPress core közvetlenül semmilyen MI-szolgáltatót nem csomagol be.

Amit a core szállít, az egy egységes PHP felület. Egy bővítmény meghívja a wp_ai_client_prompt() függvényt, amely egy WP_AI_Client_Prompt_Builder objektumot ad vissza, láncba fűzi a beállításokat, például a using_temperature() vagy a using_model_preference() hívást, majd a generate_text() vagy a generate_image() hívással zár. A hibák WP_Error formájában térnek vissza, a kérések a WordPress HTTP rétegén mennek át, és az egész a hookrendszerbe kapcsolódik.

A gyakorlati hatás az, hogy egy bővítményszerző többé nem ír HTTP klienst, újrapróbálkozó ciklust, kulcstároló képernyőt és beállítási oldalt minden egyes modellszolgáltatóhoz. Leírja, mit szeretne, a core pedig továbbítja.

Ez valódi csökkenés a párhuzamosan írt kódban. Egyben a bizalom központosítása is, és éppen ezen érdemes gondolkodni, mielőtt bármit bekapcsol.

Mi az a connector

A connector a webhelye és egy külső szolgáltatás közötti nyilvántartott kapcsolat. A 7.0 kiadásban az egyetlen connector típus az MI-szolgáltatóké, és három kiemelt bővítmény fedi le az Anthropic, a Google és az OpenAI szolgáltatását, mindegyiket külön kell telepíteni.

A Connectors API fejlesztői jegyzete leírja, hogyan oldódnak fel a hitelesítő adatok. Egy kulcs jöhet környezeti változóból, PHP konstansból vagy adatbázis-beállításból, ebben a sorrendben ellenőrizve, az opciónevek pedig a connectors_ai_{$id}_api_key mintát követik.

Egy részlet minden webhelyért felelős ember figyelmét megérdemli. A jegyzet szerint az adatbázisban tárolt API-kulcsok nincsenek titkosítva, csak a felületen vannak elfedve, a titkosítás pedig későbbi munkaként szerepel. Ha az adminfelületen ad meg egy kulcsot, az nyílt szövegként ül a wp_options táblában, és annak az adatbázisnak minden mentése tartalmaz mostantól egy díjköteles hitelesítő adatot.

Mit jelent ez, ha nem programoz

Egy webhelytulajdonos számára a változás egyszerűbb, mint amilyennek hangzik. Semmi nem generál, nem foglal össze és nem ír át semmit, amíg két dolog nem igaz: telepítve van egy szolgáltatói bővítmény, és valaki beillesztett egy működő kulcsot a Beállítások, majd Connectors képernyőn.

Addig az AI Client alvó programkönyvtár. A WordPress 7.0 verzióra frissítés nem küldi el a bejegyzéseit egy modellnek, nem hoz létre fiókot sehol, és nem keletkezik belőle számla.

Amit viszont megtesz, az a következő telepített bővítmény küszöbének leszállítása. Az a bővítmény, amelynek korábban kulcsot kellett kérnie öntől, most találhat egy már beállítottat a webhelyen, és használhatja azt. Ez kényelmes, és pontosan az a dolog, amiről érdemes szabályzatot írni, mielőtt véletlenül megtörténik.

Az Abilities API és miért változik a bővítménytervezés

Az Abilities API az a darab, amely három év múlva is számítani fog, és önmagában semmi köze az MI-hez. Ez egy nyilvántartás. Egy bővítmény a wp_register_ability() hívással regisztrál egy megnevezett funkcióegységet namespace/ability-name alakban, ember által olvasható leírással, a bemenetekhez és kimenetekhez tartozó JSON Schema definícióval, egy végrehajtási visszahívással és egy elhagyható jogosultsági visszahívással.

A hivatalos dokumentáció a jogosultsági visszahívást szokásos képességellenőrzésként mutatja be, amely például a current_user_can( 'manage_options' ) értéket adja vissza. Ez a teljes biztonsági modell, és pontosan annyit ér, amennyit a bővítmény szerzőjének ítélőképessége.

Amint léteznek abilities elemek, más programok fel tudják sorolni őket. Egy modellnek átadható a lista arról, mire képes éppen ez a webhely, séma formájában, és a modell meg tud hívni egyet közülük. Ugyanez igaz egy kliensoldali Command Palette megoldásra, ezért került az API JavaScript fele ugyanabba a kiadásba, mint a paletta.

A tervezési következmény a bővítményszerzők számára valós. Az a funkció, amely korábban csak a saját adminképernyőjén, a saját nonce értékével és a saját űrlapjával volt elérhető, most olyasmi, amit gép által olvasható szerződéssel, ability formájában várhatnak el öntől. Ez más támadási felület és más dokumentációs teher.

Mi változott a 7.1 verzióban

A WordPress 7.1 szigorította a nyilvántartást, nem bővítette. A 7.1 abilities fejlesztői jegyzete hozzáadja a wp_ability_validate_input és wp_ability_validate_output ellenőrző szűrőt, a végrehajtás elején elsülő wp_ability_invoked eseményt, valamint egy public metaadatjelzőt, amely szabályozza, hogy egy ability felfedezhető legyen-e REST felületen a /wp-json/wp-abilities/v1/abilities címen.

Ez a jegyzet hordozza azt a mondatot is, amelyet minden naplózó bővítmény szerzőjének el kellene olvasnia. A meghívási hook nyers, nem normalizált bemenetet kap, és a fejlesztőknek kerülniük kell a bemenet válogatás nélküli naplózását, mert az tartalmazhat hitelesítő adatokat, személyes adatokat vagy más érzékeny információt.

A valós idejű együttműködés és a tábla, amire szüksége lett volna

Az együttműködő szerkesztés a Yjs könyvtárra épül, egy ütközésmentes replikált adattípusra, szinkronizációs szolgáltatói absztrakcióval. A core alapértelmezetten HTTP lekérdezésen alapuló szolgáltatót szállít, amelyet a WebSocket helyett választottak, mert minden tárhelyen működik, a bővítmények pedig szűrővel cserélhetik le az átvitelt.

A probléma soha nem az összefésülő algoritmus volt. Az volt, hogy hol laktak a szinkronizációs adatok. Az eredeti megvalósítás a post meta mezőkben tárolta őket, ami WordPressben a kézenfekvő választás, és a rossz választás olyan adatokhoz, amelyek másodpercenként többször változnak.

A post meta írások gyorsítótár-érvénytelenítést váltanak ki. Nyitott szerkesztő mellett a szinkronizációs adatok folyamatosan íródtak, így minden írás kiürítette az adott bejegyzéshez tartozó gyorsítótárazott lekérdezéseket. A gyakorlatban egyetlen ember, aki egy oldalt szerkesztett, a munkamenet teljes hosszán át folyamatos ürítésben tarthatta a webhely tartós objektum-gyorsítótárát.

Ez jó általános tanulság a post meta mezőkről. Kulcs-érték tároló, amely ahhoz a tartalomhoz kötött gyorsítótár-életcikluson lóg, amelyhez tartozik, és rendben van olyan attribútumokhoz, amelyek a bejegyzéssel együtt változnak. Nem jegyzettömb nagy gyakoriságú állapothoz.

A megmért javítás és a döntés

A közreműködők nyolc tárhelykörnyezetben teszteltek tárolási stratégiákat. A teljesítményelemzés arra jutott, hogy a tranziensekre épülő külön tábla nagyjából 52% gyorsabb volt a meglévő megvalósításnál, egy egyszerű külön tábla pedig nagyjából 37% gyorsabb. Jelen lévő tartós objektum-gyorsítótár mellett mindkét tranziens alapú stratégia egyetlen adatbázis-lekérdezésre esett vissza küldésenként.

A tranziensekkel működő saját táblát választották. Aztán ugyanazon a napon a funkciót kihúzták.

Az eltávolítási közlemény a támadási felülettel, a versenyhelyzetekkel, a kiszolgáló terhelésével, a memóriahatékonysággal és a fuzz teszteléssel talált visszatérő hibákkal kapcsolatos aggályokra hivatkozik, és azt írja, a döntés azért született, hogy a felhasználók stabil és megbízható WordPress 7.0 kiadást kapjanak.

Hol tart most

A 7.1 kiadásban sem jelent meg. A 7.1 terepkalauza kimondja, hogy a valós idejű együttműködő szerkesztés kiterjedt tesztelést és visszajelzést kapott a WordPress 7.1 ciklusa alatt, de a végleges kiadásban nincs bekapcsolva.

A Notes, a rokon, de külön funkció a blokkszintű megjegyzésekhez, megjelent, és a 7.1 kiadásban formázott szöveggel és @ említésekkel bővült. Ha egy ügyfél Google Docs stílusú közös szerkesztést kér WordPressben, ma az őszinte válasz az, hogy a Notes lefedi az átnézési folyamatot, az egyidejű gépelés viszont továbbra sincs a core részeként.

Az adminfelület változásai és a hibajegyek, amiket szülnek

Két változás fog támogatási kéréseket termelni, és egyik sem hiba.

A Ctrl+K vagy Cmd+K billentyűre nyíló Command Palette valóban gyors, ha az ember megtanulta, csakhogy a Ctrl+K sok szerkesztőben a hivatkozás beszúrásának gyorsbillentyűje, és néhány felhasználó jelenteni fogja, hogy elromlott a hivatkozás beszúrása. Nem romlott el; a fókusz kontextusa dönti el, melyik kezelő nyer.

A megújított vezérlőpult a nagyobb ügy. Minden ügyfélnek, akinek a munkatársait képernyőképeken tanították be, elavult lett az oktatási anyaga, és minden bővítmény, amely adminképernyőkre injektált jelölést, adott osztályokat vagy DOM szerkezetet feltételezve, furcsán jelenhet meg. Ez inkább kozmetikai, mint működésbeli kérdés, de a frissítés napján érkezik, minden webhelyen, minden felhasználónál, ezért ez a kiadás leglátványosabb része azok számára, akik nem fejlesztők.

Számoljon ügyfelenként egy órával egy rövid, írásos tájékoztatóra új képernyőképekkel, mielőtt bármit frissítene. Olcsóbb, mint ugyanezt tizenötször elmagyarázni e-mailben.

Az igazi kompatibilitási kérdés

A verziószámozás töréssel járó kiadást sejtet. A PHP követelmények nem. Ahogy a PHP támogatásról szóló pontosítás leszögezi, a minimálisan támogatott PHP verzió a WordPress 7.0 óta a 7.4, a minimálisan ajánlott verzió pedig továbbra is a 8.3. A PHP 7.2 és 7.3 támogatása ebben a kiadásban megszűnt.

A pontosítás visszavonta a újabb PHP verziókra használt régi béta címkét is, és rögzíti a PHP 8.5 teljes támogatását a WordPress 6.9 és 7.0 kiadásban.

A támogatott és az ésszerű közötti szakadék a lényeg. A PHP 7.4 2022 novemberében érte el élettartama végét, tehát egy webhely, amely épp csak átlépi a minimumot, olyan értelmezőn fut, amely közel négy éve nem kapott biztonsági javítást. Ha a tárhelye 2026-ban még mindig a 7.4 verzión áll, nem a WordPress verziója a legsürgetőbb gondja.

A törés a gyakorlatban kiszámítható mintát követ. Az elhagyott bővítmények buknak először, különösen bármi, ami az admin DOM szerkezetét vagy a szerkesztő iframe elemét manipulálja. Az egyedi sablonok bedrótozott admin stílussal rosszul néznek ki. A saját React csomagot szállító oldalépítők a szerkesztőben megjelenő fehér oldalak szokásos forrásai, és rendszerint ők javítanak a leggyorsabban.

Konkrét frissítési eljárás

Építsen staging környezetet. Klónozza az éles rendszert az adatbázissal együtt olyan környezetbe, amely nem indexelhető és nem küld levelet. Az alábbiak közül semmit nem érdemes élő webhelyen csinálni.

Rögzítse a kiindulási állapotot. Jegyezze fel a PHP verziót, a bővítmények és sablonok listáját a verziószámokkal, valamint az aktuális WordPress verziót. Készítsen képernyőképeket arról a két vagy három adminképernyőről, amelyet az ügyfél naponta használ.

Először csak a WordPresst frissítse. Hagyja érintetlenül a bővítményeket és a sablonokat, majd járja végig a nyilvános oldalt, a bejegyzésszerkesztőt, a webhelyszerkesztőt, a WooCommerce pénztárát, ha van, és minden egyedi adminképernyőt. Az itt jelentkező hiba a core-hoz vagy egy nem kompatibilis kiterjesztéshez tartozik, és épp ennek a bővítményfrissítéstől való elválasztása az egész oka ennek a sorrendnek.

Utána kis csomagokban frissítse a bővítményeket, a csomagok között újratesztelve, hogy egy visszalépésnek rövid gyanúsítotti listája legyen.

Nézze a hibanaplókat, ne a szemével az oldalakat. Egy elavult hívásból származó PHP figyelmeztetés nem mindig jelenik meg láthatóan, és hónapokig csendben tölti a naplót.

Hagyja üresen a Connectors képernyőt. Adja ki a frissítést beállított MI-szolgáltató nélkül, és kezelje a bekapcsolást külön, szándékos változtatásként, saját jóváhagyással. A WordPress biztonsági megerősítési listánk lefedi a körülötte lévő védelmeket, a teljesítményauditálási útmutató pedig azt, mit kell utána mérni.

Irányítás: mit tehet meg egy connector

Itt van az a kérdés, amelyet az abilities réteg teremt, és amelyet egyetlen bővítményszerző sem válaszolhat meg ön helyett. Egy harmadik féltől származó bővítmény regisztrálhat olyan ability elemet, amely ügyféladatokat olvas, felhasználókat exportál vagy közzétett tartalmat szerkeszt, és egy modell, amely hozzáfér a nyilvántartáshoz, meghívhatja azt. A jogosultsági visszahívás képességellenőrzés, tehát a modell annak a jogaival cselekszik, aki be van jelentkezve.

Ha az az ember adminisztrátor, a modell adminisztrátori dolgokat tehet. Ez nem tervezési hiba, hanem a dokumentált terv működés közben. Azt viszont jelenti, hogy annak eldöntése, mely connectors elemek léteznek egy webhelyen, adatvédelmi döntés, nem informatikai ízlés kérdése.

Egy CMS tartalma ritkán csak marketingszöveg. A hozzászólások, az űrlapbeküldések, a rendelési adatok és a felhasználói profilok személyes adatok, elküldésük egy külső modellnek pedig olyan adatkezelés, amelyet indokolni kell tudnia. Az ICO útmutatója az MI-ről és az adatvédelemről rögzíti az elszámoltathatósági és átláthatósági elvárásokat, köztük a beépített adatvédelmet.

Egy ügyfélwebhely gyakorlati minimuma egy rövid, írásos szabályzat: mely connectors elemek engedélyezettek, ki adhat hozzá újat, mely abilities elemek nyilvánosak REST felületen, és mi a megőrzési álláspont a szolgáltatónál. Írja meg, mielőtt valaki beilleszt egy kulcsot, mert utána már incidensjelentés lesz belőle, nem szabályzat.

Mi jön ezután

A WordPress 7.1 2026. augusztus 19-én érkezett reszponzív stílusvezérlőkkel a Global Styles felületen, a szerkesztőkön átívelő állandó adminsávval, rendes médiaszerkesztő ablakkal, Playlist és Tabs blokkokkal, valamint a már említett Notes fejlesztésekkel. Befejezte továbbá az iframe alapú bejegyzésszerkesztőre való átállást, azoknál a webhelyeknél is, amelyek régi meta dobozokat regisztrálnak, és ez a változás fedi fel a legnagyobb eséllyel a régi bővítményeket.

A WordPress 7.2 kiadást 2026 utolsó főverziójaként tervezik. A 7.2 kiadási oldala a végleges kiadást 2026. december 8 és 10 közötti ablakba teszi, a béták október végétől indulnak. Ez az ütemterv terv és nem tény, ez a projekt pedig idén már elmozdított egy főverziós dátumot.

Az együttműködő szerkesztés marad a kézenfekvő jelölt egy jövőbeli kiadásra, de már kettőt elszalasztott, és senkinek nem szabad dátumot ígérnie rá egy ügyfélnek.

Mi változik üzletileg

Három ügyfélbeszélgetés változik meg, és csak az egyik szól az MI-ről.

Az első a frissítésről szóló beszélgetés. A WordPress 7.0 és 7.1 megéri, hogy felügyelt frissítésként, staging körrel számlázzák, mert az iframe alapú szerkesztő és az adminfelület átalakítása valóban felszínre hozza a régi kiterjesztéseket. Ezt fix áras csomagként, írásos tesztterv mellett eladni őszintébb és jövedelmezőbb, mint egy átalánydíjba beolvasztani, majd este hatkor felfedezni egy törött oldalépítőt.

A második az irányítás. A connectors szabályzat, az abilities átvizsgálása és a hitelesítő adatok kezelése számlázható tanácsadói munka, amely 2026 májusa előtt nem létezett, és sokkal jobban illik egy ügynökséghez, mint egy házon belüli marketingcsapathoz.

A harmadik az építési munka. Az AI Client leveszi az MI-funkció webhelybe építésének unalmas felét, ami csökkenti a vezetékezés árát, és megemeli annak értékét, hogy tudjuk, mit érdemes megépíteni. Ha ezt egy egyedi fejlesztéssel méri össze, a WordPress és az egyedi fejlesztés összehasonlításunk megmutatja, hol húzódik általában a határ, a WordPress fejlesztői díjakról szóló jegyzeteink pedig azt, mennyibe kerüljön a munka.

A Mecanik a core verziófrissítéseket, a connectors irányítást és az MI-funkciók fejlesztését a WordPress fejlesztés és az MI-integráció szolgáltatásaink részeként végzi. A minta, amit látunk, állandó: maga a frissítés rutin, a drága meglepetések pedig olyan kiterjesztésekből jönnek, amelyeket három éve senki nem nézett át.

Gyakran ismételt kérdések

Mikor jelent meg a WordPress 7.0 és miért csúszott? A WordPress 7.0 Armstrong kiadásnéven 2026. május 20-án jelent meg, hat héttel az eredeti ütemterv április 9-i dátuma után. A csúszás célja a valós idejű együttműködő szerkesztés megvalósításáról érkező tesztvisszajelzések kezelése volt, a ciklus pedig a release candidate után visszatért bétába. Az együttműködő szerkesztést végül 2026. május 8-án kivették a kiadásból.

Elküldi a WordPress 7.0 a tartalmamat egy MI-szolgáltatónak? Nem. A core tartalmaz egy AI Client komponenst, de nem csomagol MI-szolgáltatót, modellt vagy API-kulcsot. Semmi nem megy sehová, amíg egy adminisztrátor nem telepít szolgáltatói bővítményt és nem ment működő hitelesítő adatot a Beállítások, majd Connectors képernyőn. Addig az AI Client alvó programkönyvtár, amely semmibe nem kerül és semmit nem továbbít.

Mire való az Abilities API? Nyilvántartás, amelyben egy bővítmény megnevezett funkcióegységet deklarál, JSON Schema bemenetekkel és kimenetekkel, jogosultsági visszahívással és végrehajtási visszahívással. Más szoftverek, köztük MI-modellek és a Command Palette, ezután fel tudják sorolni, mire képes egy webhely, és meg tudják hívni. A PHP fele a WordPress 6.9 kiadásban jelent meg, a JavaScript fele a 7.0 kiadásban.

Milyen PHP verziót igényel a WordPress 7.0? A minimálisan támogatott verzió a WordPress 7.0 óta a PHP 7.4, amely megszüntette a PHP 7.2 és 7.3 támogatását. A minimálisan ajánlott verzió továbbra is a PHP 8.3. Mivel a PHP 7.4 2022 novemberében érte el élettartama végét, a puszta minimum támogatás nélküli értelmezőt jelent, ezért a 8.3 vagy újabb verziót tekintse valódi követelménynek.

Elérhető már a valós idejű együttműködő szerkesztés? A core-ban nem. Tizenkét nappal a kiadás előtt kivették a WordPress 7.0 verzióból a versenyhelyzetekkel, a kiszolgáló terhelésével és a memóriahatékonysággal kapcsolatos aggályok miatt, és a WordPress 7.1 kiadásban sincs bekapcsolva. A külön Notes funkció, amely blokkszintű megjegyzéseket tesz lehetővé említésekkel, megjelent, és az átnézési folyamatot fedi le, nem az egyidejű gépelést.