WordPress plaanib 2026. aastaks taas kolm suuremat tuumaversiooni: 7.0 ettevalmistus käib

WordPressi Core committers’i (tuumakoodi põhihaldajate) kvartaalne check-in andis üsna konkreetse signaali: 2026. aastal tahetakse uuesti jõuda kolme suure (major) WordPressi väljalaskeni. Koos tempoga vaadati üle ka varajane plaan WordPress 7.0 jaoks, räägiti admin-liidese uuendusest ning sellest, mis rolli võiks tulevikus mängida AI (tehisintellekt) WordPressi ökosüsteemis.

Oluline kontekst: veel sama aasta jooksul oli WordPressi Executive Director Mary Hubbard öelnud, et 2026. aastal tuleb vaid üks major release, tuues põhjuseks “ongoing legal matters” (viide WP Engine’i kohtuvaidlusele) ning Automatticu panuse vähendamise WordPressi arendusse. Nüüd paistab, et sisemine hoiak on muutunud ning fookus on taas regulaarsemal väljalaskerütmil.

Kohtumine toimus Chatham House Rule’i raames, mis tähendab, et sisu võib jagada, kuid ei tohiks omistada konkreetseid väiteid konkreetsetele osalejatele. Arutelu kokkuvõtte avaldas Make WordPress Core blogis core committer Jonathan Desrosiers.

2026: tagasi kolme major release’i juurde (ja 7.0 ajastus)

Kohtumise märkmete järgi on järgmiseks aastaks “intention” ehk selge kavatsus taastada kolme väljalaske rütm. WordPress 7.0 on esialgu sihitud märtsiks või aprilliks.

Veebruari väljalase välistati. Põhjus on praktiline: kui 7.0 tuleks veebruaris, kukuks Beta 1 väga varasesse jaanuarisse, mil paljud panustajad on veel puhkusel ning mitu pooleliolevat funktsiooni ei oleks ajaliselt valmis.

Laual käis ka mõte siduda tulevased major release’id suuremate “lipulaeva” sündmustega (näiteks nagu WordPress 6.9 lansseerimine State of the Word’i ajal). Samas nenditi, et selline koordineerimine muudaks protsessi keerulisemaks: reisimine, ajavööndid ning release squad’i ja teiste panustajate kättesaadavus lisavad riske.

WordPress 7.0 võimalikud funktsioonid: 6.9 plaanidest AI Client’ini

Arutelus käisid 7.0 kandidaatidena läbi mitmed asjad, mis olid varem skoopitud WordPress 6.9 jaoks:

• template activation
• Tabs block
• Abilities API (täpsemalt: Abilities API client-side abilities)
• client-side media editing

Suurim ja sisukaim arutelu koondus aga WordPress AI Client’i ümber. See on üks WordPressi AI Team’i neljast nn Building Blocks’ist ning seda kaalutakse nüüd ka tuuma (core) osaks toomise vaates.

Mis asi on WordPress AI Client?

WordPress AI Client on SDK-laadne klient, mis annab pluginatele ja teemadele natiivse ning provider-agnostic (teenusepakkujast sõltumatu) viisi AI-teenustega suhtlemiseks. Praktikas tähendab see, et plugin ei pea kõvakodeerima, kas ta kasutab näiteks ühe või teise pakkuja mudelit – kliendi eesmärk on pakkuda WordPressi-stiilis ühtset abstraktsiooni.

Kohtumise ajaks oli äsja väljastatud WordPress AI Client’i versioon 0.1.0. See kohandab olemasolevat PHP AI Client’i WordPressi tavadele ning ehitab peale mõned WordPressi jaoks väga olulised tükid:

• kasutab WordPress HTTP API-t (ehk WordPressi enda HTTP-kihiga standardset viisi väliste päringute tegemiseks)
• koondab API võtmete halduse eraldi “AI Credentials” ekraanile
• tegeleb mudeli (model) valikuga nii, et pluginad ei peaks konkreetseid pakkujaid hard-code’ima

Märkmetes toodi välja ka see, mida järgmised väljalasked peaksid lisama:

• Abilities API tugi
• REST endpoint’id
• client-side Prompt Builder

Miks nähakse AI Client’i tugeva kandidaadina tuuma jaoks?

Põhjendus on üsna arendajakeskne: kui ökosüsteem hakkab AI funktsionaalsust ehitama, siis on mõistlik teha seda ühtsete ja “õigete” vundamentide peale (näiteks Abilities API). Kohtumise märkmetes sõnastati mõte nii, et AI Client sobib ideaalselt Core’i koju, sest seotud API-de kombineerimine avaks arendajatele ja saidiomanikele palju võimalusi.

Piirangud: WordPress peab jääma agnostiliseks

Samas rõhutati ka selgeid piiranguid. WordPress “will always remain agnostic” – ehk tuuma sisse ei ole jätkusuutlik panna ühte konkreetset AI mudelit või lukustuda ainult osade kolmandate teenustega integreerimise peale.

Pikemas vaates mainiti, et võimalusi võivad avada esilekerkivad masinapõhised või brauseritaseme mudelid (machine-based / browser-level models), kuid mingit kindlat suunda selles arutelus ei valitud.

Enne otsust: selged kasutusjuhtumid “default WordPressis”

Enne kui AI Client’i tuuma toomisest saab reaalne otsus, soovitakse lauale tuua konkreetsed kasutusjuhtumid, mis töötaksid ka ilma erilise “AI pluginapargita” – ehk nii, et need oleksid mõistetavad ja väärtuslikud “default WordPressi” kasutajale. Näidetena nimetati:

• meediateegi (Media Library) otsing konkreetse teemasisu või objekti järgi
• uudiskirjade genereerimine hiljutise sisu põhjal

Admin-liidese redesign: pigem värske värvikiht kui totaalne ümbertegemine

Admin-ala uuendus (admin redesign) tuli samuti jutuks. Kohtumise sõnum oli, et eesmärk ei ole teha täielikku ümberkorraldust, vaid pigem anda “fresh coat of paint” – värskendada olemasolevat ning parandada seda, mis juba on.

See täpsustus on oluline, sest varasemates aruteludes (sh juuli kvartaalne kohtumine) oli kõlanud, et redesign’i võiks katsetada eksperimendina Gutenberg pluginas või eraldi “MP7” pluginana. Nimi viitab MP6-le – 2013. aastal tehtud “feature as a plugin” lähenemisele, mis mõjutas WordPress 3.8 admin-disaini uuendust.

Admin redesign seotakse Gutenberg roadmap’i Phase 3: Collaboration etapiga. Töö selle suuna kallal käivitati juba 2023. aastal, kui Gutenbergi juhtarhitekt Matías Ventura jagas visiooni admin-kogemuse moderniseerimiseks ning demonstreeris hiljem 2023 State of the Word’i ajal uusi paigutusi.

Tasub tähele panna, et varajane admin redesign’i eelvaade, mis oli algselt plaanitud WordPress 6.9 kõrvale, pandi septembris pausile. Roadmap’i uuenduses märgiti see siis kui “no longer planned based on the current state of work”.

Minimaalne PHP versioon: miks räägitakse 7.4 peale tõstmisest

Veel üks teema, mis mõjutab otseselt arenduspraktikat ja pluginate/teemade ühilduvust: minimaalse toetatud PHP versiooni tõstmine. Kohtumisel otsiti “compelling reasons” ehk veenvaid põhjuseid, miks miinimum võiks liikuda PHP 7.4 peale.

Argumentatsioon oli pigem insenertehniline ja praktiline:

• vanemate PHP versioonide toetamine sunnib WordPressi hoidma ühilduvust, mis lisab “bloat”’i (kohmakust/ülekasvu) ja aeglustab arendust
• PHP 7.4 aitaks liikuda järjekindlama tüübikasutuse (consistent typing) suunas
• uuem miinimum teeb koodibaasi lihtsamini mõistetavaks nii arendajatele kui ka AI-süsteemidele
• paljud kolmandate osapoolte AI SDK-d eeldavad juba niikuinii uuemaid PHP versioone; liiga madal miinimum takistab nende kasutamist

Samas raamistati teemat kui tasakaalu leidmist progressi ja kasutajate kaasas hoidmise vahel – eesmärk ei ole kedagi maha jätta. Kohtumisel otsust siiski ei tehtud.

Mis jäi lauale järgmisteks sammudeks

Jonathan Desrosiers pani kohtumise lõpus kirja ka konkreetse järeltegevuste loetelu, mida tuuma tiim soovib edasi liigutada:

• pakkuda välja avatumad ja pool-avatud (semi-open) koosolekuformaadid
• avalikustada 2026. aasta väljalaskegraafik
• kinnitada WordPress 7.0 (ja võimalik, et ka 7.1) sihitud funktsioonid
• hinnata, kas väljalasete koordineerimine kohapealsete (in-person) sündmustega on päriselt teostatav

Kokkuvõte: mida see tähendab arendajale ja tootetiimile

Kui 2026. aastal tõesti taastub kolme major release’i rütm ja 7.0 tuleb märtsis/aprillis, siis tähendab see WordPressi ökosüsteemis taas tihedamat muutuste tsüklit. Samal ajal on näha, et suured strateegilised teemad (AI Client tuumas, admin-kogemuse moderniseerimine, PHP miinimumi tõstmine) vajavad veel selgeid kasutusjuhtumeid ja teostatavuse kinnitamist – mitte ainult tehnilist entusiasmi.