Prima di unirmi al coro di entusiasmo per il rilascio, lasciami partire da quello che ho scritto qualche giorno fa su LinkedIn, ovvero che questa è una release che punta molto sull’intelligenza artificiale nativa ma che si dimentica di alcune mancanze strutturali, come la localizzazione nativa, e chiude gli occhi davanti ad alcuni problemi di performance.
Il mio timore è che WordPress stia in parte guardando il dito invece della luna, perché chi vuole restare il leader di un settore non lo fa con le funzionalità di tendenza, lo fa con basi solide. E le basi di WordPress, nel 2026, hanno ancora qualche buco che secondo me dovrebbe stare tra le priorità da gestire:
Detto questo, devo ammettere che il lavoro tecnico entrato in questa release è davvero buono, e merita di essere letto per quello che è e non soltanto per quello che manca.
- la localizzazione multilingua nativa semplicemente non esiste, e continuiamo a installare plugin di terze parti per qualcosa che dovrebbe essere nel core almeno dal 2010;
- la gestione SEO di base resta delegata a Yoast, Rank Math o a qualche altro plugin;
- il modello dati è ancora quello di un blog del 2003, con i tipi di contenuto personalizzati ammassati tutti nella stessa tabella;
- le opzioni vengono caricate in memoria ancora prima che WordPress sappia quale pagina gli stai chiedendo.
Le novità di WordPress 7.0
La cosa principale in questa nuova release di WordPress è ovviamente l’intelligenza artificiale, con un’infrastruttura AI integrata nel core, costruita attorno a un client che permette a WordPress di dialogare con i modelli generativi, a una schermata centrale di gestione delle connessioni e alla Abilities API, con un plugin AI opzionale per arrivare a generare e modificare immagini, creare titoli o riassunti e suggerire testi alternativi.
L’area di amministrazione è stata rinfrescata, con un tema dai toni più puliti, transizioni morbide tra le schermate e una nuova barra di ricerca rapida, la cosiddetta Command Palette, richiamabile ovunque con una scorciatoia da tastiera (CTRL+K), un dettaglio che sembra piccolo ma che, una volta entrato nelle dita, cambia il ritmo del lavoro. Arrivano inoltre una pagina dedicata alla gestione dei font, uniforme su temi a blocchi, ibridi e classici, e un miglioramento della visualizzazione delle revisioni che permette di capire con un colpo d’occhio cosa è cambiato.
Sul fronte della progettazione dei contenuti il set di strumenti si allarga in modo concreto: fanno il loro ingresso due nuovi blocchi, Breadcrumb per la navigazione e Icone, mentre il blocco Titolo viene rilavorato e la Galleria guadagna una lightbox che ora funziona come uno slideshow navigabile con frecce e pulsanti avanti e indietro, mentre i controlli di responsività diventano granulari, con la possibilità di nascondere o mostrare blocchi per dispositivo senza intaccare gli altri punti di interruzione e di personalizzare i breakpoint stessi.
Si aggiungono il menu in overlay costruito con blocchi e pattern, i pattern che si comportano come singola unità staccabile e il CSS personalizzato applicabile a livello di singolo blocco.
La collaborazione in tempo reale è stata rimandata, ma eviterò di farne un dramma, perché nel concreto l’avrebbe usata davvero soltanto una minoranza di redazioni strutturate. La release è il frutto di oltre novecento contributori, con quasi trecento alla prima esperienza, più di quattrocento tra miglioramenti e correzioni, e una traduzione già disponibile in oltre settanta lingue.
DataViews, le nuove tabelle React
Qui c’è il cambiamento che più merita attenzione tecnica, perché tocca una delle strutture più antiche e più usate di WordPress. Le DataViews sono la sostituzione, basata su React, delle storiche tabelle elenco costruite attorno a WP_List_Table e renderizzate dal server, quelle delle schermate di articoli, pagine e media. Al posto della vecchia tabella statica ottieni un’interfaccia che offre più viste, dalla tabella alla griglia alla lista, e che gestisce filtri, ordinamenti e operazioni in blocco lato client, quindi in modo istantaneo e senza ricaricare la pagina. Per chi amministra molti contenuti il guadagno in fluidità è reale, e per chi sviluppa significa avere finalmente un pattern coerente per presentare insiemi di dati invece di reinventare ogni volta la propria tabella.
C’è però una precisazione che le headline più entusiaste saltano, e che invece per noi fa la differenza: nella 7.0 la migrazione riguarda le schermate core di articoli, pagine e media, mentre le schermate elenco dei tipi di contenuto personalizzati non sono ancora state convertite e continuano a basarsi su WP_List_Table, con i loro hook e le loro colonne personalizzate che funzionano come prima. È una transizione progressiva, destinata a proseguire nelle versioni successive, il che significa che oggi convivono due paradigmi nella stessa installazione.
E qui si annida il rischio pratico. Se usi o sviluppi plugin che aggiungono colonne, filtri, azioni in blocco o campi di modifica rapida proprio sulle schermate di articoli, pagine e media, è concreto che alcuni di questi elementi non vengano renderizzati correttamente finché i rispettivi autori non rilasceranno le patch di compatibilità. A questo si sommano, sotto il cofano, un editor a blocchi ormai isolato in un iframe e un’applicazione più rigorosa dei permessi sulle API REST, due cambiamenti da mettere in conto prima di toccare un sito di produzione carico di personalizzazioni.
Blocchi Gutenberg gestiti da PHP
Questa è la novità che mi è piaciuta di più, perché abbassa una barriera che per anni ha tenuto lontani dal mondo dei blocchi proprio gli sviluppatori PHP più esperti. Fino a ieri, costruire un blocco dinamico significava quasi sempre avviare un piccolo progetto JavaScript completo di build e dipendenze, anche quando il blocco doveva solo restituire del markup generato dal server. Con la 7.0 puoi creare blocchi, e perfino pattern, interamente a livello server usando solo PHP, registrandoli automaticamente attraverso l’API dei blocchi, e WordPress genera da sé i controlli dell’inspector per i tipi di attributo più comuni. Il meccanismo è un singolo flag, autoRegister, da passare dentro l’array dei supports insieme a un render callback.
In pratica, se il blocco non ha bisogno di interattività lato client nell’editor, salti del tutto la parte JavaScript, con un vantaggio anche prestazionale, perché ti risparmi il peso di una registrazione appesantita da script che, in molti casi orientati al server, sarebbero stati inutili.
Qui trovi un esempio minimo che rende l’idea: un blocco di avviso registrato interamente in PHP, senza un solo file JavaScript, senza block.json e senza cartella src/.
Attorno a questa novità si muove un toolbox per sviluppatori più ampio. La Field API si estende e si allinea con Block Bindings e con la sovrascrittura dei pattern, rendendo più naturale costruire blocchi che attingono i valori da campi personalizzati, fonti esterne o valori calcolati, senza incollare a mano i dati nel template.
Il client AI nativo
Il client AI nativo non è un assistente che scrive al posto tuo, non è una chat che compare nella bacheca e non è un pulsante magico che genera articoli: è infrastruttura per chi sviluppa. WordPress non genera nulla da solo, non spedisce nulla a nessun fornitore finché non sei tu, con codice esplicito, a chiederglielo, e non include alcun provider preconfigurato nel core. È un motore senza benzina: progettato benissimo, ma fermo finché non gli dai un fornitore e gli dici cosa fare.
L’architettura si regge su quattro mattoni complementari. Il primo è il WP AI Client, cioè l’API in PHP, indipendente dal fornitore, che offre a plugin e temi un’unica interfaccia per costruire prompt, inviarli a un modello e gestirne la risposta; è costruito sopra al PHP AI Client, una libreria indipendente dal framework, con costruttore di prompt fluente, schermata di amministrazione per le credenziali e collegamento automatico delle chiavi salvate nelle opzioni.
Il secondo è la Abilities API, che svolge il compito opposto: mentre il client serve a chiamare un modello dall’interno del tuo codice, la Abilities API dichiara quali azioni il tuo sito sa compiere e le rende scopribili dall’esterno, con schema JSON per ingressi e uscite e con un controllo dei permessi affidato a una funzione dedicata per ogni abilità. In 7.0 arriva anche la sua controparte lato client, un pacchetto JavaScript con interfaccia integrata e palette di comandi, che apre alle abilità ibride e agli agenti nel browser. Il terzo mattone è la schermata delle connessioni, che raccoglie in un unico posto la configurazione dei fornitori, con tre preset pronti o connessioni proprie, così che una connessione impostata una volta sola valga per tutti i plugin. Il quarto è l’adattatore per il Model Context Protocol, che espone le abilità registrate come strumenti che qualunque client compatibile, da Claude a strumenti analoghi, può scoprire e richiamare.
Insieme, questi pezzi risolvono il problema che chiunque abbia integrato l’AI in WordPress conosce bene: ogni plugin costruiva la propria connessione, custodiva le proprie chiavi e ignorava gli altri, con l’utente a gestire la stessa chiave in cinque posti diversi e lo sviluppatore a riscrivere ogni volta la stessa logica di autenticazione.
Come funziona
Il punto di ingresso è sorprendentemente semplice. La chiamata più elementare per generare del testo si riduce a una riga, con uno stile fluente che chi viene dal PHP moderno riconoscerà al volo.
// Generazione di testo nella sua forma più essenziale.
// wp_ai_client_prompt() costruisce il prompt, generate_text() lo invia
// al provider configurato e restituisce la stringa generata.
$riassunto = wp_ai_client_prompt( 'Riassumi questo articolo in una frase.' )
->using_system_instruction( 'Scrivi riassunti concisi. Restituisci solo testo semplice.' )
->generate_text();
Esiste anche una forma equivalente basata su una classe, utile quando preferisci uno stile più esplicito, e in entrambi i casi puoi configurare i parametri di generazione, ad esempio abbassando la temperatura per ottenere risposte più deterministiche.
use WordPress\AI_Client\AI_Client;
// Stessa operazione, sintassi basata sulla classe, con temperatura bassa
// per un output più prevedibile e meno creativo.
$testo = AI_Client::prompt( 'Riassumi la storia della stampa a caratteri mobili.' )
->using_temperature( 0.1 )
->generate_text();
Il lato JavaScript offre un’interfaccia speculare, appoggiata sotto il cofano agli endpoint REST.
// Versione lato client, con costruttore di prompt analogo a quello PHP.
const testo = await wp.aiClient
.prompt( 'Scrivi un breve sommario di questo post.' )
.generateText();
Due accorgimenti separano un esperimento da un plugin scritto bene. Il primo è la degradazione elegante: verifica sempre che l’infrastruttura sia disponibile prima di mostrare una funzionalità che ne dipende, altrimenti offrirai pulsanti che non fanno nulla.
// Mostra la funzionalità AI solo se il client è disponibile,
// altrimenti guida l'utente verso la configurazione.
if ( function_exists( 'wp_ai_client_prompt' ) ) {
// Qui esponi la funzionalità basata sull'intelligenza artificiale.
} else {
// Qui mostri le istruzioni per installare un provider e configurarlo.
}
Il secondo riguarda i permessi, e qui la documentazione ufficiale è netta: per i plugin distribuiti pubblicamente è sconsigliato chiamare l’API JavaScript direttamente, perché richiederebbe controlli di capacità a livello di amministratore per impedire che un utente non fidato invii prompt arbitrari ai provider configurati, con i relativi costi e rischi di sicurezza. Il pattern raccomandato è esporre la logica come abilità lato server, ciascuna protetta dalla propria funzione di controllo dei permessi, e richiamarla dal client. Esiste a questo scopo una capacità dedicata, assegnata di default ai soli amministratori, che governa chi può inviare richieste ai modelli.
Plugin per Claude e Gemini
Indipendente dal fornitore significa che il tuo codice viene scritto una volta sola e funziona con qualunque provider configurato sul sito, senza una riga da cambiare. Il plugin che genera una descrizione SEO non sa, e non deve sapere, se dietro c’è OpenAI, Anthropic o Google: chiede a WordPress di generare del testo, e WordPress instrada la richiesta verso il fornitore collegato dall’amministratore.
Da qui il punto pratico: il core, da solo, non parla con nessuno. Per usare Claude di Anthropic installi il plugin del provider Anthropic, per usare Gemini installi quello di Google, e lo stesso vale per OpenAI. Il team che cura l’area AI ha già pubblicato sul repository ufficiale i plugin per questi tre fornitori principali, mentre la comunità ha aggiunto provider per servizi come Grok, OpenRouter e perfino Ollama per chi vuole far girare i modelli in locale. Installato il plugin, imposti la chiave tramite una variabile d’ambiente o una costante, e da quel momento ogni plugin costruito sul WP AI Client può usare quel fornitore.
C’è anche un meccanismo per esprimere preferenze sul modello senza incatenarsi a una scelta: indichi un ordine di preferenza, e il client prova i modelli nell’ordine indicato, ripiegando su una selezione automatica se quello richiesto non è disponibile e restituendo un errore pulito invece di forzare un modello incompatibile.
// Indica una preferenza ordinata di modelli: il client prova il primo,
// poi il secondo, infine ripiega sulla selezione automatica.
$risposta = wp_ai_client_prompt( 'Descrivi questa immagine.' )
->using_model_preference( 'claude-sonnet-4-6', 'gpt-5.3' )
->generate_text();
Una nota di prospettiva che la documentazione ripete: l’idea di lungo periodo è che siano gli hosting a includere i provider, sollevando l’utente finale, quasi sempre non tecnico, dall’incombenza di procurarsi e configurare una chiave. Per questo, oggi, il consiglio realistico è concentrarsi su cosa puoi costruire con questa infrastruttura più che su come l’utente medio dovrebbe collegarsi al fornitore, perché quella parte è destinata a semplificarsi.
Conclusione su WordPress 7.0
Avrei preferito vedere questa enorme energia indirizzata altrove, perché tra una localizzazione finalmente nativa e un client AI nel core avrei firmato per la prima senza pensarci, e lo stesso vale per il caricamento delle opzioni, un peso che si trascina da troppo tempo su ogni singola richiesta. La parte di gestione dell’intelligenza artificiale la accolgo con un certo scetticismo, non perché sia fatta male, anzi, ma perché alimenta l’idea pericolosa che basti delegare e lasciare lì il codice generato come una scatola nera che nessuno saprà più aprire tra due anni, quando invece delegare senza capire non è una strategia ma soltanto debito tecnico travestito da produttività.
E però, a essere giusti prima ancora che critici, hanno fatto un bel lavoro.
L’infrastruttura AI è progettata con una pulizia che si fa apprezzare, indipendente dal fornitore e rispettosa per davvero della scelta dell’utente, le DataViews portano una modernità che all’area di amministrazione mancava da troppo, e i blocchi in PHP sono esattamente quel tipo di intervento sulle fondamenta che vorrei vedere più spesso, perché abbassano una barriera invece di alzarne una. Il dito, questa volta, è ben curato, e qua e là si intravede pure la luna.
Se sviluppi plugin o temi per WordPress che toccano l’intelligenza artificiale, l’amministrazione o i blocchi, la release ti riguarda da subito e vale la pena studiarla in profondità. Ma se gestisci un sito che funziona e che non ha bisogno immediato né di DataViews né di un client AI, soprattutto se è carico di plugin che intervengono sulle schermate di articoli, pagine e media, non c’è alcuna fretta: fai un backup completo, prova prima su un ambiente di staging, lascia che la comunità segnali le prime incompatibilità, e aggiorna con calma. Le fondamenta, dopotutto, restano lì ad aspettarti, e una settimana di prudenza non ha mai fatto male a nessuno.
Per approfondire
- Annuncio ufficiale di WordPress 7.0 “Armstrong”
- WordPress 7.0 Field Guide,
- WP AI Client, handbook ufficiale
