WordPress revine la trei release-uri majore în 2026: primele discuții pentru 7.0, AI Client, redesign de admin și PHP minim 7.4

În ultimele luni, discuțiile despre ritmul de livrare (release cadence) în WordPress au fost mai tensionate decât de obicei: între planificare tehnică, capacitate de contribuție și contextul juridic care a influențat direct resursele proiectului. Într-un check-in trimestrial cu core committers și leadership, proiectul a conturat acum o direcție diferită pentru 2026: revenirea la trei release-uri majore și startul planificării pentru WordPress 7.0.

Întâlnirea a fost desfășurată sub Chatham House Rule, ceea ce explică de ce concluziile apar mai degrabă ca direcții și intenții decât ca decizii finale nominalizate. Pe agendă au intrat: calendarul de release pentru 2026, fereastra probabilă pentru WordPress 7.0, funcționalități candidate (inclusiv WordPress AI Client), stadiul redesign-ului de admin și posibilitatea ridicării versiunii minime de PHP.

De ce contează schimbarea: de la „un singur major release” la trei în 2026

Concluzia principală a întâlnirii: WordPress este setat să revină la trei versiuni majore în 2026. E o schimbare notabilă față de începutul anului, când Executive Director Mary Hubbard anunțase că în 2026 va exista un singur major release, invocând „ongoing legal matters” – o trimitere la disputa juridică din jurul WP Engine – și în paralel reducerea contribuțiilor Automattic la WordPress.

Practic, discuția despre cadence nu mai e doar o preferință de product management; e o problemă de capacitate reală (câți oameni pot livra), coordonare între echipe și predictibilitate pentru ecosistem (pluginuri, teme, hosting, agenții).

Trei release-uri majore în 2026 și ținta pentru WordPress 7.0

Potrivit notițelor publicate pe Make WordPress Core de core committer-ul Jonathan Desrosiers, intenția este reluarea ritmului de trei release-uri majore anul viitor, cu WordPress 7.0 vizat pentru martie sau aprilie.

O lansare în februarie a fost exclusă, pentru că ar împinge Beta 1 la început de ianuarie – exact perioada în care mulți contributori sunt încă în concediu – iar mai multe funcționalități aflate în lucru nu ar fi gata la timp.

Lansări aliniate cu evenimente „flagship”: idee, nu plan

În întâlnire s-a discutat și posibilitatea alinierii release-urilor majore cu evenimente importante (flagship events), pe modelul lansării WordPress 6.9 care a coincis cu State of the Word. Totuși, grupul a subliniat că o astfel de sincronizare adaugă complexitate: călătorii, fusuri orare, disponibilitatea release squad-ului și a contributorilor.

În acest moment, ideea rămâne o posibilitate, nu un plan. A fost marcată pentru discuții ulterioare, tocmai pentru a evalua dacă beneficiile de comunicare și coordonare depășesc costul operațional.

Ce ar putea intra în WordPress 7.0: de la Tabs block la WordPress AI Client

O parte din funcționalitățile care fuseseră inițial luate în calcul pentru WordPress 6.9 au revenit pe masă ca posibili candidați pentru 7.0. În discuții au apărut:

• template activation
• Tabs block
• client-side abilities pentru Abilities API (un API care descrie „capabilități” utilizabile de diverse componente)
• client-side media editing (editare media în browser)

Cea mai amplă dezbatere s-a concentrat însă pe WordPress AI Client.

WordPress AI Client: SDK nativ, agnostic de provider, posibil candidat pentru Core

WordPress AI Client este unul dintre cele patru „Building Blocks” din roadmap-ul AI Team și, în acest moment, este luat în calcul pentru includere în WordPress Core. Versiunea 0.1.0 a WordPress AI Client a fost livrată recent, iar ideea de bază este să ofere o cale nativă (WordPress-native), agnostic de provider, prin care pluginurile și temele pot interacționa cu servicii AI.

Clientul adaptează PHP AI Client la convențiile WordPress și mizează pe infrastructura pe care o avem deja în ecosistem. Concret, conform descrierilor din notițele întâlnirii și anunțului de lansare, WordPress AI Client:

• folosește WordPress HTTP API pentru request-uri către servicii AI
• centralizează cheile API într-un ecran dedicat, numit „AI Credentials”
• gestionează selecția modelului fără să forțeze pluginurile să „hard-codeze” provideri specifici (de ex. un singur vendor)

Planurile pentru release-uri viitoare ale AI Client includ, de asemenea:

• suport pentru Abilities API
• REST endpoints
• un Prompt Builder pe client-side (un builder în browser pentru compunerea prompturilor)

Motivul pentru care core committers îl văd ca un candidat puternic pentru core ține de „fundație”: dacă vrei un ecosistem sănătos, ai nevoie de interfețe și convenții stabile, pe care pluginurile să construiască într-un mod compatibil. În notițele întâlnirii, argumentul este formulat explicit: includerea AI Client în Core ar încuraja ecosistemul să construiască pe baze solide (precum Abilities API), iar combinarea acestor API-uri poate deschide multe posibilități atât pentru dezvoltatori, cât și pentru ownerii de site-uri.

Constrângeri: WordPress trebuie să rămână agnostic (și AI-ul nu poate fi „un singur provider”)

În același timp, discuțiile au subliniat limitele: WordPress „va rămâne mereu agnostic”. Asta înseamnă că includerea unui model AI specific sau integrarea doar cu anumite servicii third-party nu este sustenabilă pe termen lung.

A fost menționată și perspectiva că, pe termen mai lung, oportunități interesante ar putea veni din modele emergente bazate pe machine sau direct la nivel de browser. Nu s-a ales însă o direcție concretă în această întâlnire.

Înainte de o decizie: use case-uri clare pentru „default WordPress”

Înainte ca AI Client să fie acceptat în core, contributorii vor să vadă use case-uri clare în WordPress „out of the box”. Exemplele vehiculate au fost foarte concrete:

• căutare în Media Library după subiect (de exemplu, să găsești imagini cu un anumit tip de conținut)
• generarea de newslettere pe baza conținutului recent publicat

Redesign-ul de admin: nu o revoluție, ci o „împrospătare”

Redesign-ul zonei de administrare a apărut din nou în discuție, cu o clarificare importantă: obiectivul nu este un overhaul complet, ci mai degrabă o aplicare a unui „fresh coat of paint” – adică o împrospătare a ceea ce există deja.

Această nuanță vine în contextul discuțiilor din întâlnirea trimestrială din iulie, când se analizase ideea de a testa redesign-ul ca experiment fie în pluginul Gutenberg, fie ca un plugin separat de tip „MP7”. Referința la MP7 este intenționat un nod către MP6, modelul „feature as a plugin” folosit în 2013, care a influențat redesign-ul de admin din WordPress 3.8.

Unde se încadrează în roadmap: Gutenberg Phase 3 (Collaboration)

Redesign-ul de admin este parte din Phase 3: Collaboration, în roadmap-ul Gutenberg. Munca pe această direcție a început în 2023, când Matías Ventura (Gutenberg Lead Architect) și-a publicat viziunea pentru modernizarea experienței de administrare, iar ulterior a demonstrat layout-uri noi în State of the Word 2023.

De ce nu a ajuns în 6.9 și ce știm despre timeline

Un early preview al redesign-ului, care fusese inițial planificat să vină alături de WordPress 6.9, a fost pus pe pauză în septembrie. În update-ul de roadmap, inițiativa a fost marcată ca „no longer planned based on the current state of work”.

Momentan, nu există un timeline pentru când admin-ul redesenat ar putea ajunge efectiv în WordPress. Ultima împrospătare majoră a admin-ului a fost livrată în WordPress 3.8, adică acum mai bine de un deceniu.

PHP minim 7.4: „compelling reasons”, dar fără decizie finală

Un alt subiect care atinge direct dezvoltatorii și companiile de hosting: ridicarea versiunii minime suportate de PHP la 7.4. În întâlnire s-au explorat „compelling reasons” pentru această schimbare, însă nu s-a luat o decizie în cadrul sesiunii.

De ce împinge proiectul spre 7.4 (din perspectivă practică)

Discuția a fost centrată pe limitele practice ale compatibilității cu versiuni vechi de PHP. Argumentele principale:

• compatibilitatea cu PHP mai vechi obligă WordPress să păstreze constrângeri care adaugă bloat (cod și condiționări în plus) și încetinesc dezvoltarea
• PHP 7.4 ar muta codebase-ul spre typing mai consistent, ceea ce ajută atât dezvoltatorii, cât și sistemele AI să înțeleagă mai ușor codul
• multe SDK-uri AI third-party cer deja versiuni mai noi de PHP; un minim prea jos blochează adoptarea lor în proiect

Echilibrul: progres fără a „lăsa pe cineva în urmă”

Întreaga conversație a fost încadrată ca un exercițiu de echilibru: proiectul vrea să progreseze, dar fără să piardă utilizatori și fără să creeze o barieră bruscă pentru site-urile care încă rulează pe infrastructură veche. De aici și faptul că, cel puțin în această întâlnire, nu s-a anunțat o schimbare concretă.

Ce urmează după check-in: puncte de follow-up asumate

Jonathan Desrosiers a notat o listă de acțiuni de follow-up rezultate din sesiune. Printre ele:

• propunerea unor formate de întâlnire mai deschise și semi-deschise
• publicarea programului de release pentru 2026
• confirmarea funcționalităților țintite pentru WordPress 7.0 și, posibil, 7.1
• evaluarea practică a ideii de a coordona release-urile cu evenimente in-person

Concluzie: 2026 se anunță din nou „rapid”, dar cu decizii de fundație

Revenirea la trei release-uri majore în 2026 schimbă așteptările pentru toată lumea: de la echipele care întrețin pluginuri și teme, până la hosting și agenții care planifică upgrade-uri și compatibilități. În același timp, discuțiile pentru WordPress 7.0 arată că proiectul se uită la decizii de fundație: un strat standard pentru integrarea AI (WordPress AI Client), o modernizare de admin care promite mai degrabă consistență și refresh decât o ruptură, și presiunea tot mai mare de a ridica minimul de PHP pentru a elimina frânele tehnice.