WordPress 2026 m. grįžta prie trijų pagrindinių leidimų: startuoja ankstyvas 7.0 planavimas

2025 m. pabaigos „Core Committers Check-in“ (ketvirtinis susitikimas tarp branduolio komiteriŲ ir projekto vadovybės) atnešė reikšmingą naujieną: 2026 m. WordPress planuoja grįžti prie trijų pagrindinių (major) leidimų ritmo. Tuo pačiu jau pradėtos ankstyvos diskusijos apie WordPress 7.0 kryptį: kokios funkcijos galėtų patekti į 7.0, kaip judės admin dizaino perpiešimas, kokią vietą ekosistemoje užims AI įrankiai ir ar laikas kelti minimalią palaikomą PHP versiją.

Svarbus kontekstas: metų pradžioje WordPress vykdomoji direktorė Mary Hubbard buvo paskelbusi, kad 2026 m. planuojamas tik vienas pagrindinis leidimas – motyvuojant „vykstančiais teisiniais klausimais“. Tai buvo siejama su WP Engine ieškiniu bei Automattic sprendimu pristabdyti WordPress indėlį ir „sulyginti“ jį su WP Engine, kol tęsiasi teisinė kova. Dabar, remiantis šio ketvirčio susitikimo užrašais, kryptis vėl keičiasi – į trijų major versijų modelį.

2026 m. leidimų ritmas: „intencija“ grįžti prie trijų major versijų

Remiantis Make WordPress Core įrašu su susitikimo užrašais (juos publikavo core committer Jonathan Desrosiers), komanda įvardijo aiškią „intenciją“ 2026 m. atnaujinti trijų pagrindinių leidimų per metus ritmą. Kaip orientyras 7.0 versijai minimas kovo arba balandžio laikotarpis.

Vasario leidimas buvo atmestas. Priežastis praktiška: jei 7.0 būtų taikomasi į vasarį, „beta 1“ kristų į pačią sausio pradžią, kai daug dalyvių dar atostogauja. Be to, dalis šiuo metu vystomų funkcijų paprasčiausiai nespėtų pasiekti tokio brandos lygio, kad būtų realu jas stabiliai išleisti pagal tokį grafiką.

Ar major leidimai bus derinami su didžiaisiais renginiais?

Susitikime taip pat aptarta idėja ateities major leidimus derinti prie „flagship“ renginių – panašiai kaip šiemet WordPress 6.9 išleidimas buvo susietas su „State of the Word“.

Visgi šiai idėjai įvardinta ir kaina: leidimų derinimas prie kelionių, laiko zonų, release squad (leidimo komandos) bei platesnių bendruomenės pajėgumų gali pridėti nemažai koordinavimo sudėtingumo. Dėl to tai šiuo metu laikoma galimybe, o ne patvirtintu planu, ir pažymėta kaip tema tolimesnėms diskusijoms.

Kas galėtų patekti į WordPress 7.0: nuo Tabs bloko iki AI Client

Kartu su leidimų planavimu aptartos ir funkcijos, kurios iš pradžių buvo numatytos WordPress 6.9 apimtyje, bet dabar svarstomos kaip kandidatės į 7.0. Tarp paminėtų krypčių:

• Template activation (šablonų aktyvavimas)
• Tabs block (kortelių / skirtukų blokas)
• Client-side galimybės Abilities API kontekste
• Client-side media editing (kliento pusės medijos redagavimas)

Vis dėlto didžiausia ir išsamiausia diskusijų dalis sukosi apie WordPress AI Client – komponentą, kuris dabar jau rimtai svarstomas kaip kandidatas būti įtrauktas į WordPress core.

WordPress AI Client: kas tai ir kodėl tai svarbu branduoliui

WordPress AI Client – tai native (platformiškai „savas“) ir provider-agnostic (tiekėjo atžvilgiu neutralus) būdas pluginams ir temoms integruotis su AI paslaugomis. Praktikoje tai reiškia, kad kuriant AI funkcionalumą nereikia kiekvienam įskiepiui atskirai „prisirišti“ prie vieno konkretaus tiekėjo ar hardcodinti specifinių modelių – atsiranda bendras, WordPress stilių atitinkantis sluoksnis integracijoms.

Pagal paskelbtą informaciją, WordPress AI Client 0.1.0 versija pasirodė prieš savaitę iki aptariamo susitikimo. Ji adaptuoja PHP AI Client į WordPress konvencijas ir sprendžia kelias labai praktiškas problemas:

• Naudoja WordPress HTTP API užklausoms į AI paslaugas (vietoje to, kad kiekvienas įskiepis atsineštų savo HTTP sluoksnį).
• Centralizuoja API raktus per „AI Credentials“ ekraną (viena vieta valdyti kredencialus).
• Sprendžia modelio parinkimą taip, kad pluginams nereikėtų hardcodinti konkrečių provider’ių.
• Formuoja pagrindą ekosistemai kurti ant bendrų pamatų, susijusių su Abilities API.

Taip pat aiškiai įvardinta, kas planuojama ateities AI Client laidose:

• Abilities API palaikymas
• REST endpoint’ai
• Client-side Prompt Builder (kliento pusės užklausų / promptų konstruktorius)

Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

Susitikimo užrašai (Make WordPress Core)

Core įtraukimo ribos: WordPress turi likti neutralus

Jei AI Client keliaus į core, komanda aiškiai akcentuoja kelis apribojimus ir principus. Pirmas – WordPress „visada išliks agnostinis“: įtraukti konkretų AI modelį arba integruotis tik su dalimi trečiųjų šalių paslaugų ilgalaikėje perspektyvoje nėra tvaru.

Taip pat buvo paliestos ir ilgalaikės galimybės: ateityje daugiau potencialo gali atsirasti iš besiformuojančių machine-based ar browser-level modelių (pvz., veikiančių arčiau įrenginio / naršyklės). Tačiau jokios krypties susitikime nebuvo pasirinkta.

Prieš sprendimą – aiškūs „default WordPress“ naudojimo scenarijai

Prieš priimant sprendimą dėl AI Client vietos core, dalyviai nori matyti aiškiai suformuluotus naudojimo scenarijus „default WordPress“ aplinkoje – t. y. ką AI duos ne tik integruotojams ar produktų komandoms, bet ir standartinei WordPress instaliacijai. Kaip pavyzdžiai minimi:

• Medijos bibliotekos paieška pagal konkretų turinį / temą (pvz., rasti nuotraukas su tam tikru objektu ar siužetu).
• Naujienlaiškių generavimas remiantis neseniai publikuotu turiniu.

Admin perpiešimas: ne revoliucija, o „šviežias dažų sluoksnis“

Kita svarbi tema – admin sąsajos (wp-admin) atnaujinimas. Susitikimo metu dalyviams buvo aiškiai pasakyta, kad tikslas nėra pilnas perstatymas nuo nulio. Vietoje to kalbama apie „new coat of paint“ – t. y. švelnesnį atnaujinimą, kuris atgaivina tai, kas jau yra, bet nesiekia radikaliai keisti visų admin paradigminių sprendimų.

Šis patikslinimas svarbus dėl ankstesnio konteksto: per liepos ketvirčio susitikimą buvo aptarta, ar perpiešimą testuoti kaip eksperimentą Gutenberg įskiepyje, ar leisti atskirą „MP7“ įskiepį. Tai būtų aliuzija į MP6 – 2013 m. „feature as a plugin“ modelį (kai funkcija pirmiausia vystoma kaip įskiepis), kuris stipriai suformavo WordPress 3.8 admin dizaino atnaujinimą.

Admin perpiešimas yra Gutenberg kelrodžio (roadmap) Phase 3: Collaboration dalis. Darbai šia kryptimi prasidėjo 2023 m., kai Gutenberg Lead Architect Matías Ventura pasidalijo savo vizija modernizuoti administravimo patirtį, o vėliau 2023 m. „State of the Word“ metu demonstravo naujus išdėstymus.

Įdomi detalė: ankstyvas admin perpiešimo „preview“, kurį iš pradžių buvo planuota išleisti kartu su WordPress 6.9, rugsėjį buvo padėtas į šalį. Roadmap atnaujinime tuomet atsirado formuluotė, kad tai „no longer planned based on the current state of work“ – kitaip tariant, pagal esamą progreso būklę tai nebėra suplanuota.

Šiuo metu vis dar nėra aiškios datos, kada perpieštas admin galėtų pasiekti WordPress core. Paskutinis didelis admin atnaujinimas buvo išleistas daugiau nei prieš dešimtmetį – WordPress 3.8 laikais.

Minimalios PHP versijos kėlimas: kodėl kalbama apie 7.4?

Susitikime taip pat ieškota „įtikinamų priežasčių“ kelti minimalią palaikomą PHP versiją iki 7.4. Diskusija buvo labiau apie realius techninius limitus nei apie formalų „norą atsinaujinti“.

Pagrindinė argumentų ašis tokia: senesnės PHP versijos verčia WordPress ilgai išlaikyti suderinamumo sluoksnius, kurie didina „bloat“ (apkrautumą) ir lėtina vystymą. PHP 7.4 riba, pagal aptartus motyvus, leistų:

• Judėti link nuoseklesnio tipavimo (typing) visame kode.
• Palengvinti kodo „suprantamumą“ tiek žmonėms programuotojams, tiek AI sistemoms, kurios analizuoja kodą.
• Atsirišti nuo dalies dirbtinių apribojimų, kuriuos kelia labai seni PHP palaikymo įsipareigojimai.

Dar vienas praktiškas argumentas – trečiųjų šalių AI SDK. Buvo pastebėta, kad nemaža jų dalis jau reikalauja naujesnių PHP versijų. Jei WordPress minimumas lieka per žemas, projektas negali realistiškai naudoti tokių SDK (arba tai tampa neproporcingai sudėtinga).

Tuo pačiu diskusija aiškiai buvo įrėminta kaip balanso paieška: progresas prieš suderinamumą ir norą „nepalikti nieko už borto“. Susitikimo metu sprendimas nebuvo priimtas.

Kas toliau: atviri formatai, grafikas ir 7.0/7.1 apimtys

Susitikimo pabaigoje Jonathan Desrosiers užfiksavo kelis konkrečius „follow-up“ punktus, kuriuos komanda norėtų pajudinti po šios sesijos:

• Pasiūlyti atviresnius ir pusiau atvirus susitikimų formatus (more open and semi-open meeting formats).
• Publikuoti 2026 m. leidimų grafiką (release schedule).
• Patvirtinti taikomas 7.0 (ir galimai 7.1) funkcijas.
• Įvertinti, ar realu ir praktiška major leidimus koordinuoti su gyvais, fiziniais renginiais (in-person events).

Trumpa santrauka WordPress kūrėjams

Jei dirbi su WordPress produktais ar klientiniais projektais, iš šių diskusijų verta išsinešti kelis aiškius signalus. 2026 m. vėl taikomasi į trijų major leidimų ritmą, o 7.0 langas realistiškai stumiamas į kovą–balandį. AI kryptis stiprėja per AI Client (provider’ių atžvilgiu neutralų SDK sluoksnį), admin atnaujinimas pozicionuojamas kaip evoliucija, o ne revoliucija, o PHP minimumo kėlimas iki 7.4 grįžta į rimtesnę darbotvarkę – nors sprendimų kol kas nėra.