WordPress punta di nuovo a tre major release nel 2026: si apre la pianificazione per la 7.0 (AI Client, admin redesign e PHP minimo)

Nel check-in trimestrale tra core committers e leadership di progetto (fine novembre 2025) è emersa un’indicazione chiara: nel 2026 WordPress intende tornare a una cadenza di tre major release. È un cambio di passo importante, perché solo qualche mese prima era stata comunicata l’ipotesi opposta: una sola major release nel 2026.

Oltre al calendario, l’incontro ha toccato temi che interessano direttamente chi sviluppa temi e plugin: la pianificazione iniziale di WordPress 7.0, la direzione del redesign dell’area admin, e le motivazioni (ancora in discussione) per alzare la versione minima di PHP supportata. Sullo sfondo, un argomento che nel 2026 diventerà difficile ignorare: come integrare l’AI nell’ecosistema senza “legarsi” a un singolo provider.

Nota di contesto: la riunione si è svolta sotto Chatham House Rule (regola che consente di usare le informazioni emerse, senza attribuirle a singoli partecipanti).

Dal “solo una major nel 2026” al ritorno a tre release

L’intenzione di ripartire con tre release major nel 2026 è stata riportata nelle note pubblicate su Make WordPress Core dal core committer Jonathan Desrosiers. È un ribaltamento rispetto a quanto comunicato in precedenza dalla Executive Director Mary Hubbard, quando si parlò di una sola major release nel 2026 a causa di “ongoing legal matters” (un riferimento alla causa legale che coinvolge WP Engine) e in parallelo al ridimensionamento delle contribuzioni di Automattic al progetto WordPress nel contesto della stessa disputa.

WordPress 7.0: target marzo/aprile, niente release a febbraio

Per WordPress 7.0 il target discusso è marzo o aprile. È stata invece esclusa una release a febbraio, perché significherebbe portare Beta 1 a inizio gennaio: un momento in cui molti contributor sono ancora in ferie e, soprattutto, diverse funzionalità in lavorazione non sarebbero pronte in tempo.

Release “agganciate” agli eventi principali: idea interessante, ma complessa

Nel confronto è tornata anche un’idea che ciclicamente riemerge: allineare le major release a eventi di punta, sulla scia del lancio di WordPress 6.9 durante lo State of the Word. Il gruppo ha però evidenziato che coordinare una release con viaggi, fusi orari e disponibilità di release squad e contributor aggiunge complessità operativa.

Per ora rimane una possibilità, non un piano: è stata esplicitamente segnalata come tema da riprendere in ulteriori discussioni.

Cosa potrebbe entrare in WordPress 7.0: feature ex-6.9 e focus sull’AI Client

Nel check-in sono state citate alcune funzionalità che erano state inizialmente considerate per WordPress 6.9 e che ora rientrano tra le candidate per 7.0. In particolare:

• template activation
• Tabs block (blocco Tabs)
• abilitazioni lato client per l’Abilities API (API pensata per descrivere e verificare “capacità”/abilità in modo consistente)
• client-side media editing (editing dei media lato client)

La parte più corposa della discussione, però, ha ruotato attorno al WordPress AI Client.

WordPress AI Client: cos’è e perché si parla di portarlo in core

Il WordPress AI Client è uno dei quattro “Building Blocks” definiti dall’AI Team nella roadmap iniziale e viene ora valutato come possibile componente di WordPress core. La versione 0.1.0 è stata rilasciata la settimana precedente al meeting.

Tecnicamente, l’AI Client è un SDK (Software Development Kit) pensato per offrire a plugin e temi un modo nativo e provider-agnostic di interagire con servizi AI. In pratica, l’obiettivo è evitare che ogni plugin debba reinventare la ruota (e le scelte architetturali) per chiamare un modello o un provider diverso.

Dalle note emerge che il progetto adatta il PHP AI Client (repository su GitHub) alle convenzioni WordPress e che, tra i punti chiave, include:

• uso della WordPress HTTP API per le chiamate in uscita
• centralizzazione delle API key in una schermata dedicata chiamata “AI Credentials”
• gestione della selezione del modello senza obbligare i plugin a hardcodare un provider specifico

Le release future previste per l’AI Client dovrebbero aggiungere:

• supporto per Abilities API
• REST endpoints
• un Prompt Builder lato client (uno strumento per comporre/gestire prompt direttamente nel contesto client)

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.

Meeting notes (Make WordPress Core)

Questa “funzione di piattaforma” è il motivo per cui diversi committer lo vedono come un buon candidato per il core: crea fondamenta comuni e incentiva l’ecosistema a costruire in modo coerente attorno a API condivise (in particolare l’Abilities API).

Vincoli: WordPress vuole restare agnostico (e non può inseguire integrazioni parziali)

Portare l’AI Client nel core apre però anche una serie di vincoli strategici. Le note ribadiscono che WordPress “will always remain agnostic”: includere un modello specifico o integrare solo alcuni servizi di terze parti non è considerato sostenibile nel lungo periodo.

È stata citata anche una prospettiva più lunga: opportunità potrebbero arrivare da modelli emergenti “machine-based” o a livello browser. Ma durante il meeting non è stata scelta una direzione precisa.

Prima di decidere: servono use case chiari nel “default WordPress”

Un punto molto pragmatico: prima di prendere decisioni sull’inclusione nel core, i contributor vogliono ragionare su use case chiari dentro l’esperienza WordPress “di default” (quella che un utente trova senza plugin). Nelle note vengono citati esempi concreti come:

• cercare nella Media Library immagini o asset in base al soggetto/argomento specifico
• generare newsletter a partire dai contenuti recenti

Admin redesign: non una rivoluzione, ma un “fresh coat of paint”

Un altro tema caldo è il redesign dell’area admin. Qui la leadership ha chiarito l’intento: non si punta a un rifacimento totale, ma a una sorta di “new coat of paint”, cioè un refresh dell’esistente più che una riscrittura completa.

La precisazione arriva dopo la riunione trimestrale di luglio, quando si era parlato di testare il redesign come esperimento nel plugin Gutenberg oppure come plugin separato in stile “MP7” (richiamando MP6 del 2013: il progetto “feature as a plugin” che ha influenzato il redesign admin di WordPress 3.8).

Questo lavoro si colloca nella Phase 3: Collaboration della roadmap Gutenberg. Il percorso è partito nel 2023, quando Matías Ventura (Gutenberg Lead Architect) ha condiviso la sua visione per modernizzare l’esperienza admin e successivamente ha mostrato nuovi layout durante lo State of the Word 2023.

Un’anteprima iniziale del redesign, che in origine era stata pianificata insieme a WordPress 6.9, è stata accantonata a settembre: l’aggiornamento della roadmap indicava che non era “no longer planned based on the current state of work” (quindi non più pianificata dato lo stato attuale dei lavori).

Ad oggi non c’è ancora una timeline su quando il nuovo admin potrebbe arrivare effettivamente. E vale la pena ricordare che l’ultimo grande refresh dell’admin risale a più di dieci anni fa, con WordPress 3.8.

Versione minima di PHP: perché si parla di alzare il requisito a 7.4

Nel meeting si è discusso anche di motivazioni “compelling” per alzare la versione minima di PHP supportata a PHP 7.4. Non è stata presa una decisione, ma i motivi messi sul tavolo sono rilevanti per chi mantiene prodotti sull’ecosistema.

Il nodo principale è un limite pratico: supportare versioni più vecchie costringe WordPress a mantenere livelli di compatibilità che aggiungono bloat (peso/complessità) e rallentano lo sviluppo.

Spostarsi su PHP 7.4, secondo quanto discusso, aiuterebbe anche a orientare la codebase verso una tipizzazione più consistente e renderebbe più facile la comprensione del codice sia per gli sviluppatori sia per sistemi AI (ad esempio strumenti di analisi o assistenti che “leggono” il codice).

È stato inoltre notato che molti SDK AI di terze parti richiedono già versioni di PHP più recenti: tenere il minimo troppo basso rischia di impedire al progetto di usarli.

La discussione è stata esplicitamente inquadrata come un equilibrio tra progresso e adozione: avanzare senza “lasciare indietro” utenti e siti che faticano ad aggiornare. Anche qui, nessuna decisione è stata presa durante l’incontro.

I prossimi passi emersi dalle note del meeting

Tra i follow-up elencati da Desrosiers nelle note, ci sono alcuni punti operativi che aiutano a capire cosa aspettarsi nel breve:

• proporre formati di meeting più aperti e semi-aperti
• pubblicare lo schedule delle release 2026
• confermare le feature target per WordPress 7.0 e possibilmente anche 7.1
• valutare se coordinare le release con eventi in presenza sia realmente praticabile

Perché questa notizia conta per chi sviluppa (plugin, temi, infrastruttura)

Il ritorno a tre major release nel 2026, se confermato con uno schedule pubblico, significa una roadmap più “vivace” e un flusso di cambiamenti più frequente. In parallelo, i temi discussi (AI Client, Abilities API lato client, media editing client-side, admin refresh e possibile PHP minimo 7.4) impattano direttamente su:

• compatibilità e supporto versioni (soprattutto lato hosting e clienti enterprise)
• scelte architetturali nei plugin che vogliono integrare AI senza lock-in su un provider
• UX e integrazioni admin (se il redesign procede come plugin sperimentale o entra progressivamente nel core)
• tooling e qualità del codice (tipizzazione, static analysis, integrazione SDK moderni)