WordPress 7.0 è uscito il 20 maggio 2026 con il nome di rilascio Armstrong, sei settimane dopo la data del calendario 2026 originale, ed è la versione di core più importante per le agenzie dai tempi del block editor. Il titolo è che il core ora sa parlare con i modelli di IA generativa. Il dettaglio che conta di più è che il core definisce anche come un plugin deve parlarci, e questo cambia in silenzio ciò che ogni plugin del sito può dare per scontato sul proprio territorio.

Per chi scrive, le modifiche visibili sono modeste: una Command Palette, una bacheca più ordinata, una schermata per la gestione dei font e revisioni migliori. Per chi mantiene siti di mestiere, le modifiche importanti stanno sotto l’amministrazione: un deposito di credenziali nella tabella delle opzioni, un registro di ciò che il sito sa fare e una superficie REST che lo elenca. Niente di tutto questo è facoltativo, perché arriva con il core e non con un plugin scelto da qualcuno.

Questa è la lettura di chi lavora sul campo. Che cosa è arrivato davvero, che cosa è stato tolto dodici giorni prima del rilascio e perché, che cosa l’aggiornamento rompe e che cosa no, e che cosa dire a un cliente che ha appena letto un titolo sull’IA dentro WordPress.

Conviene aggiornare? Sì, ma arrivate alla 7.1 invece di fermarvi alla 7.0. WordPress 7.1 è uscito il 19 agosto 2026 e la 7.0 ha quattro rilasci di manutenzione alle spalle. Le funzioni di IA restano inerti finché un amministratore non salva una chiave del fornitore in Impostazioni, poi Connectors, quindi il solo aggiornamento non manda i vostri contenuti da nessuna parte. Il rischio vero qui è la normale compatibilità di plugin e temi, non l’IA.

Che cosa è arrivato davvero in WordPress 7.0

Il rilascio prende il nome da Louis Armstrong, seguendo la convenzione del progetto di intitolare le versioni maggiori a musicisti jazz. L’annuncio di rilascio accredita più di 875 contributori e oltre 420 migliorie e correzioni.

L’elenco di ciò che è arrivato è abbastanza corto da risultare utile. Il core ha guadagnato un AI Client, un’interfaccia PHP indipendente dal fornitore per inviare prompt a modelli generativi. Ha guadagnato una schermata Connectors dentro Impostazioni, dove un amministratore conserva le credenziali del fornitore. Ha guadagnato la metà JavaScript dell’Abilities API, la cui metà PHP era già arrivata nella 6.9.

Sul versante redazionale c’è una Command Palette con Ctrl+K o Cmd+K, una bacheca modernizzata, una pagina dedicata alla gestione dei font, lo scorrimento visivo fra le revisioni e i nuovi blocchi Heading, Breadcrumbs e Icons, insieme a una presentazione in lightbox per le gallerie.

Quello che non è arrivato è la funzione attorno a cui l’intero rilascio era stato costruito. La modifica collaborativa in tempo reale è stata rimossa dodici giorni prima del lancio. Quell’assenza, e la ragione che la spiega, dicono sullo stato attuale del core più di quanto dica l’elenco delle novità.

Perché la data è slittata

Il rilascio era previsto in origine per il 9 aprile 2026. È slittato al 20 maggio perché la modifica collaborativa non era pronta e il progetto non voleva pubblicarla in quello stato. Il post sulla via da seguire dice esplicitamente che il rinvio serviva a concedere più tempo per gestire i riscontri dei test sull’implementazione della collaborazione in tempo reale, e il ciclo è tornato in beta pur mantenendo per ragioni tecniche i numeri di versione delle release candidate.

È una cosa insolita. Una versione maggiore che torna in beta dopo aver raggiunto la RC è un segnale forte, ed è stata la decisione giusta.

L’AI Client: il core fornisce l’astrazione, non il modello

Il fatto architetturale più importante di WordPress 7.0 è che il core non include un modello di IA, una chiave API o un rapporto con un fornitore qualsiasi. La nota di sviluppo sull’AI Client afferma chiaramente che il core di WordPress non include direttamente alcun fornitore di IA.

Ciò che il core fornisce è un’interfaccia PHP coerente. Un plugin chiama wp_ai_client_prompt(), che restituisce un oggetto WP_AI_Client_Prompt_Builder, concatena la configurazione come using_temperature() o using_model_preference() e chiude con generate_text() o generate_image(). Gli errori tornano come WP_Error, le richieste passano dal trasporto HTTP di WordPress e il tutto è collegato al sistema degli hook.

L’effetto pratico è che l’autore di un plugin non scrive più un client HTTP, un ciclo di ritentativi, una schermata per conservare la chiave e una pagina di impostazioni per ogni fornitore di modelli. Descrive quello che vuole e il core lo instrada.

È una riduzione reale di codice duplicato. È anche una centralizzazione della fiducia, ed è la parte su cui vale la pena ragionare prima di accendere qualsiasi cosa.

Che cos’è un connector

Un connector è la relazione registrata fra il vostro sito e un servizio esterno. Nella 7.0 l’unico tipo di connector è quello dei fornitori di IA, e ci sono tre plugin di riferimento che coprono Anthropic, Google e OpenAI, ciascuno da installare separatamente.

La nota di sviluppo sulla Connectors API descrive come si risolvono le credenziali. Una chiave può arrivare da una variabile d’ambiente, da una costante PHP o da un’impostazione nel database, controllate in quest’ordine, con nomi di opzione che seguono il modello connectors_ai_{$id}_api_key.

Un dettaglio merita l’attenzione di chiunque sia responsabile di un sito. La nota dice che le chiavi API conservate nel database non sono cifrate ma solo mascherate nell’interfaccia, e che la cifratura è rimandata a un lavoro successivo. Se impostate una chiave dalla schermata di amministrazione, resta in chiaro dentro wp_options, e ogni backup di quel database contiene ora una credenziale a pagamento.

Che cosa significa se non scrivete codice

Per chi possiede un sito il cambiamento è più semplice di quanto sembri. Nulla genera, riassume o riscrive niente finché non sono vere due cose: è installato un plugin del fornitore e qualcuno ha incollato una chiave funzionante in Impostazioni, poi Connectors.

Fino ad allora l’AI Client è una libreria dormiente. Aggiornare a WordPress 7.0 non manda i vostri articoli a un modello, non crea un account da nessuna parte e non genera alcuna spesa.

Quello che fa, invece, è abbassare la soglia per il prossimo plugin che installerete. Un plugin che prima doveva chiedervi una chiave ora può trovarne una già configurata sul sito e usarla. È comodo, ed è esattamente la cosa su cui scrivere una policy prima che accada per caso.

L’Abilities API e perché cambia la progettazione dei plugin

L’Abilities API è il pezzo che conterà ancora fra tre anni, e di per sé non ha nulla a che fare con l’IA. È un registro. Un plugin registra un’unità di funzionalità con un nome tramite wp_register_ability(), nella forma namespace/ability-name, con una descrizione leggibile, uno JSON Schema per ingressi e uscite, una callback di esecuzione e una callback di permesso facoltativa.

La documentazione ufficiale mostra la callback di permesso come un normale controllo di capacità, che per esempio restituisce current_user_can( 'manage_options' ). Questo è tutto il modello di sicurezza, e vale solo quanto il giudizio dell’autore del plugin.

Una volta che le abilities esistono, altri programmi possono enumerarle. A un modello si può consegnare l’elenco di ciò che quel preciso sito sa fare, in forma di schema, e il modello può chiamarne una. Lo stesso vale per una Command Palette lato client, ed è il motivo per cui la metà JavaScript dell’API è arrivata nello stesso rilascio della palette.

La conseguenza progettuale per gli autori di plugin è concreta. Una funzione raggiungibile solo dalla vostra schermata di amministrazione, con il vostro nonce e il vostro modulo, ora è qualcosa che potreste dover esporre come ability con un contratto leggibile dalle macchine. È una superficie di rischio diversa e un onere di documentazione diverso.

Che cosa è cambiato in 7.1

WordPress 7.1 ha stretto il registro invece di allargarlo. La nota di sviluppo sulle abilities in 7.1 aggiunge i filtri di validazione wp_ability_validate_input e wp_ability_validate_output, un’azione wp_ability_invoked che scatta all’inizio dell’esecuzione e un flag di metadati public che governa se una ability sia individuabile via REST su /wp-json/wp-abilities/v1/abilities.

Quella nota contiene anche la frase che ogni autore di plugin di logging dovrebbe leggere. L’hook di invocazione riceve ingressi grezzi e non normalizzati, e gli sviluppatori dovrebbero evitare di registrare gli ingressi in modo indiscriminato, perché possono contenere credenziali, dati personali o altre informazioni sensibili.

La collaborazione in tempo reale e la tabella che le serviva

La modifica collaborativa poggia su Yjs, un tipo di dati replicato privo di conflitti, con un’astrazione per i provider di sincronizzazione. Il core include per impostazione predefinita un provider a polling HTTP, scelto al posto dei WebSocket perché funziona su qualsiasi hosting, e i plugin possono sostituire il trasporto tramite un filtro.

Il problema non è mai stato l’algoritmo di unione. Era il posto in cui vivevano i dati di sincronizzazione. L’implementazione originale li conservava nei post meta, che in WordPress è la scelta ovvia e quella sbagliata per dati che cambiano più volte al secondo.

Le scritture sui post meta innescano l’invalidazione della cache. Con l’editor aperto, i dati di sincronizzazione venivano scritti di continuo, quindi ogni scrittura svuotava le query in cache per quell’articolo. In pratica una sola persona che modificava una pagina poteva tenere la cache oggetti persistente del sito in svuotamento continuo per tutta la sessione.

È una buona lezione generale sui post meta. Sono un archivio chiave valore agganciato al ciclo di vita della cache del contenuto a cui appartengono, e vanno benissimo per attributi che cambiano quando cambia l’articolo. Non sono uno spazio di appoggio per stati ad alta frequenza.

La correzione misurata e la decisione

I contributori hanno testato le strategie di archiviazione su otto ambienti di hosting. L’analisi delle prestazioni ha concluso che una tabella dedicata appoggiata ai transient era circa il 52% più veloce dell’implementazione esistente, e una semplice tabella dedicata circa il 37% più veloce. Con una cache oggetti persistente presente, entrambe le strategie con transient scendevano a una sola query al database per invio.

È stata scelta la tabella dedicata con i transient. Poi, lo stesso giorno, la funzione è stata rimossa.

L’avviso di rimozione cita preoccupazioni su superficie di esposizione, race condition, carico del server, efficienza di memoria e bug ricorrenti trovati con il fuzz testing, e dice che la decisione è stata presa per consegnare agli utenti un WordPress 7.0 stabile e affidabile.

A che punto siamo oggi

Non è arrivata nemmeno nella 7.1. La guida sul campo della 7.1 afferma che la modifica collaborativa in tempo reale ha ricevuto test e riscontri estesi durante il ciclo di WordPress 7.1, ma che non è abilitata nel rilascio finale.

Notes, la funzione collegata ma distinta che permette commenti a livello di blocco, è invece arrivata ed è stata migliorata nella 7.1 con la formattazione del testo e le menzioni con @. Se un cliente chiede una scrittura condivisa in stile Google Docs dentro WordPress, oggi la risposta onesta è che Notes copre il flusso di revisione e che la digitazione simultanea non è ancora nel core.

Le modifiche all’amministrazione e i ticket che generano

Due modifiche produrranno richieste di assistenza, e nessuna delle due è un difetto.

La Command Palette con Ctrl+K o Cmd+K è davvero rapida una volta imparata, ma Ctrl+K è la scorciatoia per inserire un collegamento in molti editor, e qualche utente segnalerà che l’inserimento dei link si è rotto. Non è così: è il contesto del focus a decidere quale gestore vince.

La bacheca modernizzata è la questione più grossa. Ogni cliente il cui personale è stato formato su schermate ha ora materiale di formazione superato, e ogni plugin che iniettava markup nelle schermate di amministrazione dando per scontate certe classi o una certa struttura del DOM può mostrarsi male. È una questione estetica più che funzionale, ma arriva il giorno dell’aggiornamento, su ogni sito, per ogni utente, il che la rende la parte più visibile del rilascio per chi non sviluppa.

Mettete in conto un’ora per cliente per una breve nota scritta con nuove schermate prima di aggiornare qualsiasi cosa. Costa meno della stessa spiegazione data quindici volte via email.

La vera questione di compatibilità

La numerazione suggerisce un rilascio che rompe le cose. I requisiti PHP dicono altro. Come spiega il chiarimento sul supporto a PHP, la versione minima di PHP supportata è la 7.4 da WordPress 7.0, e la versione minima consigliata resta la 8.3. Il supporto per PHP 7.2 e 7.3 è stato abbandonato in questo rilascio.

Il chiarimento ha anche ritirato la vecchia etichetta beta per le versioni più recenti di PHP e registra il pieno supporto per PHP 8.5 in WordPress 6.9 e 7.0.

Il divario fra supportato e sensato è il punto. PHP 7.4 è arrivato a fine vita nel novembre 2022, quindi un sito che supera appena il minimo gira su un interprete che non riceve correzioni di sicurezza da quasi quattro anni. Se il vostro hosting nel 2026 è ancora sulla 7.4, la versione di WordPress non è il problema più urgente.

Le rotture in pratica seguono uno schema prevedibile. I plugin abbandonati cedono per primi, in particolare tutto ciò che manipola il DOM dell’amministrazione o l’iframe dell’editor. I temi su misura con lo stile dell’amministrazione scritto a mano appaiono sbagliati. I page builder che portano i propri bundle React sono la solita origine delle pagine bianche nell’editor, e di solito sono anche i più rapidi a correggersi.

Una procedura di aggiornamento concreta

Preparate uno staging. Clonate la produzione, database compreso, in un ambiente non indicizzabile e che non invia email. Niente di quanto segue merita di essere fatto su un sito in linea.

Fissate lo stato di partenza. Annotate la versione di PHP, l’elenco di plugin e temi con le versioni e la versione attuale di WordPress. Fate le schermate delle due o tre pagine di amministrazione che il cliente usa ogni giorno.

Aggiornate prima solo WordPress. Lasciate intatti plugin e temi, poi percorrete il front end, l’editor degli articoli, l’editor del sito, il checkout WooCommerce se presente e ogni schermata di amministrazione su misura. Un guasto qui appartiene al core o a un’estensione incompatibile, e separarlo da un aggiornamento di plugin è tutto il motivo per procedere in quest’ordine.

Poi aggiornate i plugin in piccoli lotti, ripetendo i test fra un lotto e l’altro, così una regressione ha una lista corta di sospettati.

Controllate i log degli errori invece di guardare le pagine. Gli avvisi PHP di una chiamata deprecata non sempre si vedono a schermo e riempiono un log in silenzio per mesi.

Lasciate vuota la schermata Connectors. Consegnate l’aggiornamento senza alcun fornitore di IA configurato e trattate l’attivazione come una modifica separata e voluta, con una sua approvazione. La nostra checklist di hardening per WordPress copre i controlli intorno, e la guida all’audit delle prestazioni copre che cosa misurare dopo.

Governance: che cosa può fare un connector

Ecco la domanda che lo strato delle abilities crea e a cui nessun autore di plugin può rispondere al posto vostro. Un plugin di terze parti può registrare una ability che legge schede clienti, esporta utenti o modifica contenuti pubblicati, e un modello con accesso al registro può chiamarla. La callback di permesso è un controllo di capacità, quindi il modello agisce con i permessi di chi ha effettuato l’accesso.

Se quella persona è un amministratore, il modello può fare cose da amministratore. Non è un difetto della progettazione, è la progettazione che funziona come documentato. Significa però che la decisione su quali connector esistono su un sito è una decisione di protezione dei dati, non una preferenza informatica.

I contenuti di un CMS raramente sono solo testi di marketing. Commenti, invii di moduli, dati degli ordini e profili utente sono dati personali, e mandarli a un modello esterno è un trattamento che dovete saper giustificare. Le linee guida dell’ICO su IA e protezione dei dati fissano le aspettative di responsabilità e trasparenza, compresa la protezione dei dati fin dalla progettazione.

Il minimo pratico per un sito cliente è una breve policy scritta: quali connector sono ammessi, chi può aggiungerne uno, quali abilities sono esposte pubblicamente via REST e qual è la posizione sulla conservazione presso il fornitore. Scrivetela prima che qualcuno incolli una chiave, perché dopo diventa un rapporto di incidente e non una policy.

Che cosa arriva dopo

WordPress 7.1 è arrivato il 19 agosto 2026 con controlli di stile responsivi nei Global Styles, una barra di amministrazione persistente fra gli editor, una vera finestra modale per la modifica dei media, i blocchi Playlist e Tabs e le migliorie a Notes già citate. Ha inoltre completato il passaggio a un editor degli articoli dentro un iframe, anche per i siti che registrano meta box tradizionali, ed è la modifica che più facilmente smaschera un vecchio plugin.

WordPress 7.2 è previsto come ultimo rilascio maggiore del 2026. La pagina del rilascio 7.2 colloca la versione finale nella finestra dall'8 al 10 dicembre 2026, con le beta da fine ottobre. Quel calendario è previsto e non consegnato, e questo progetto ha già spostato una data di rilascio maggiore quest’anno.

La modifica collaborativa resta il candidato ovvio per un rilascio futuro, ma ne ha ormai mancati due, e nessuno dovrebbe promettere a un cliente una data.

Che cosa cambia sul piano commerciale

Cambiano tre conversazioni con il cliente, e solo una riguarda l’IA.

La prima è quella sull’aggiornamento. WordPress 7.0 e 7.1 meritano di essere fatturati come aggiornamento gestito con un passaggio in staging, perché l’editor dentro l’iframe e la nuova amministrazione smascherano davvero le vecchie estensioni. Venderlo come pacchetto a prezzo fisso con un piano di test scritto è più onesto e più redditizio che assorbirlo in un canone e scoprire un page builder rotto alle sei di sera.

La seconda è la governance. La policy sui connector, la revisione delle abilities e la gestione delle credenziali sono consulenza fatturabile che prima del maggio 2026 non esisteva, e si addicono a un’agenzia molto più che a un team di marketing interno.

La terza è il lavoro di costruzione. L’AI Client toglie la metà noiosa della realizzazione di una funzione di IA dentro un sito, il che abbassa il prezzo dell’impianto e alza il valore del sapere che cosa vale la pena costruire. Se state soppesando questo contro uno sviluppo su misura, il nostro confronto fra WordPress e sviluppo su misura mostra dove passa di solito la linea, e i nostri appunti sulle tariffe degli sviluppatori WordPress mostrano quanto dovrebbe costare il lavoro.

Mecanik segue gli aggiornamenti di versione del core, la governance dei connector e il lavoro sulle funzioni di IA nell’ambito dei nostri servizi di sviluppo WordPress e di integrazione dell’IA. Lo schema che vediamo è costante: l’aggiornamento in sé è di routine, e le sorprese costose arrivano da estensioni che nessuno ha rivisto da tre anni.

Domande frequenti

Quando è uscito WordPress 7.0 e perché è stato rinviato? WordPress 7.0, nome di rilascio Armstrong, è uscito il 20 maggio 2026, sei settimane dopo la data del 9 aprile prevista dal calendario originale. Il rinvio serviva a gestire i riscontri dei test sull’implementazione della modifica collaborativa in tempo reale, e il ciclo è tornato in beta dopo aver raggiunto la release candidate. La modifica collaborativa è stata infine rimossa dal rilascio l'8 maggio 2026.

WordPress 7.0 manda i miei contenuti a un fornitore di IA? No. Il core include un AI Client ma nessun fornitore di IA, nessun modello e nessuna chiave API. Niente viene inviato da nessuna parte finché un amministratore non installa un plugin del fornitore e non salva una credenziale funzionante in Impostazioni, poi Connectors. Fino ad allora l’AI Client è una libreria dormiente che non costa nulla e non trasmette nulla.

A che cosa serve l’Abilities API? È un registro che permette a un plugin di dichiarare un’unità di funzionalità con un nome, con ingressi e uscite in JSON Schema, una callback di permesso e una callback di esecuzione. Altri programmi, compresi i modelli di IA e la Command Palette, possono poi enumerare che cosa sa fare un sito e chiamarlo. La metà PHP è arrivata in WordPress 6.9 e la metà JavaScript nella 7.0.

Quale versione di PHP richiede WordPress 7.0? La versione minima supportata è PHP 7.4 da WordPress 7.0, che ha abbandonato il supporto per PHP 7.2 e 7.3. La versione minima consigliata resta PHP 8.3. Poiché PHP 7.4 è arrivato a fine vita nel novembre 2022, fermarsi al minimo significa far girare un interprete non più supportato, quindi trattate la 8.3 o superiore come il requisito reale.

La modifica collaborativa in tempo reale è già disponibile? Non nel core. È stata rimossa da WordPress 7.0 dodici giorni prima del rilascio per preoccupazioni su race condition, carico del server ed efficienza di memoria, e non è abilitata nemmeno in WordPress 7.1. La funzione distinta Notes, che consente commenti a livello di blocco con menzioni, è invece arrivata e copre i flussi di revisione, non la digitazione simultanea.