Il 9 aprile 2026, sul palco del WordCamp Asia a Mumbai, WordPress 7.0 avrebbe dovuto essere presentato al mondo con tutti gli onori. Non è andata così. Poche settimane prima del grande giorno, il team di sviluppo ha preso una decisione scomoda ma onesta: il rilascio viene posticipato.
Il motivo è tecnico e riguarda una funzionalità attesa di questa versione, la collaborazione in tempo reale. L’architettura del database che gestisce la sincronizzazione tra più utenti che editano lo stesso documento necessitava di una revisione strutturale, non di una semplice correzione. Detto questo, il ritardo non cambia la sostanza: WordPress 7.0 è la release più significativa dal 2018, quando arrivò Gutenberg. Vale la pena capire cosa cambia, cosa rischia di rompersi e come prepararsi con calma.
Il contesto
WordPress non pubblicava una versione “major” dal 2018, quando la 5.0 portò l’editor a blocchi Gutenberg. Da allora la numerazione è rimasta nel territorio delle versioni 5.x e 6.x, ciascuna con le proprie novità ma senza stravolgimenti architetturali profondi.
Il salto alla 7.0 segna la conclusione della Fase 3 del progetto Gutenberg. Le quattro fasi del progetto hanno ognuna un obiettivo preciso: la prima ha introdotto l’editor a blocchi, la seconda ha sviluppato il Site Editor e la Full Site Editing, la terza — quella che si chiude con la 7.0 — porta la collaborazione tra più utenti direttamente dentro WordPress. La quarta fase, prevista per il futuro, introdurrà il supporto multilingua nativo nel core.
In sintesi: WordPress sta cercando di ridurre la dipendenza da strumenti esterni come Google Docs per la revisione dei testi, Slack per il coordinamento editoriale, plugin di terze parti per le icone o il font management. Non è detto che ci riesca subito, ma la direzione è quella.
Le novità per chi usa WordPress
Collaborazione in tempo reale
È la novità più pubblicizzata e anche quella che ha causato il ritardo. Più utenti possono ora lavorare sullo stesso post o sulla stessa pagina contemporaneamente, vedendo in tempo reale cosa stanno facendo i colleghi, esattamente come avviene su Google Docs.
L’implementazione tecnica usa di default l’HTTP polling (aggiornamenti ogni pochi secondi), senza richiedere WebSocket. Questo è un dettaglio importante: significa che la funzionalità funziona su praticamente qualunque hosting, anche quelli più economici. Chi vuole una sincronizzazione ancora più fluida può abilitare i WebSocket se il proprio hosting li supporta, ma non è obbligatorio.
Una nota importante: questa funzionalità non è disponibile per chi usa ancora il plugin Classic Editor. Se il vostro flusso di lavoro dipende dall’editor classico, non potrete usare la collaborazione in tempo reale.
Note inline
Già introdotte in WordPress 6.9 in forma asincrona, le note inline in 7.0 si sincronizzano in tempo reale. È possibile lasciare commenti su specifici blocchi di testo, citare un collega con la @mention e risolvere i thread una volta che il problema è stato gestito. Chi lavora con un team editoriale o gestisce revisioni con i clienti troverà questo strumento molto comodo.
Revisioni visive
Lo strumento di revisione delle versioni esisteva già, ma era testuale e poco intuitivo. In WordPress 7.0 diventa visivo: si può confrontare una versione precedente con quella attuale direttamente nell’editor, con le modifiche evidenziate in modo chiaro (aggiunte in verde, eliminazioni in rosso). Ripristinare una versione precedente richiede un clic.
I nuovi blocchi Gutenberg
Breadcrumbs. Era uno dei blocchi più richiesti dalla comunità. Il blocco Breadcrumbs genera automaticamente il percorso di navigazione dalla homepage alla pagina corrente, adattandosi al contesto: funziona con le pagine gerarchiche, con le categorie, con i tipi di post personalizzati, con le pagine archivio e persino con le pagine di ricerca e gli errori 404. Si inserisce una volta come template part nel Site Editor e appare automaticamente su tutte le pagine. Oltre all’utilità per la navigazione degli utenti, c’è un vantaggio SEO non trascurabile: i motori di ricerca usano i breadcrumb per capire la struttura del sito e spesso li mostrano direttamente nei risultati di ricerca.
Icons. Finalmente un blocco nativo per inserire icone SVG nel contenuto, senza dover installare un plugin dedicato o incollare codice a mano. Si sceglie l’icona dalla libreria, si personalizza colore, dimensione e margini, e il gioco è fatto. La libreria iniziale è abbastanza limitata, lo diciamo subito per non creare aspettative eccessive. Il supporto per registrare raccolte di icone di terze parti è previsto nella versione 7.1.
Heading block con variazioni per livello. Ogni livello di intestazione (da H1 a H6) è ora una variazione del blocco Heading, con le relative icone nella sidebar per passare da un livello all’altro con un clic. Piccola novità, ma velocizza il lavoro quotidiano.
HTML block redesignato. Il blocco HTML ha ricevuto un redesign completo: funziona ora come editor modale con tre tab separate, una per HTML, una per CSS e una per JavaScript. Utile per chi ha bisogno di inserire snippet di codice personalizzati senza toccare il tema o i file del sito.
Miglioramenti ai blocchi esistenti
Gallery con lightbox nativo. Attivando l’opzione “Ingrandisci al clic” sulla Gallery, le immagini si aprono in una sovrapposizione a schermo intero navigabile con le frecce o con la tastiera. Niente più plugin dedicati per questo.
Cover con video di sfondo. Le sezioni hero con video in loop erano già possibili con alcuni page builder o con codice personalizzato. Ora è una funzionalità nativa del blocco Cover, direttamente dall’editor.
Grid responsive. Il blocco Grid gestisce ora in modo automatico il layout su schermi di dimensioni diverse, senza richiedere CSS personalizzato o plugin aggiuntivi.
Image con editor migliorato. Ritaglio, rotazione, zoom su un’area specifica, controllo del focal point e gestione dell’aspect ratio per gli allineamenti wide e full: tutte operazioni ora accessibili direttamente dall’editor senza uscire dalla pagina.
Navigation con overlay mobile personalizzabili. La creazione dei menu mobile diventa più semplice, con overlay personalizzabili e possibilità di salvare il menu come template part.
Altre novità per gli utenti
Visibilità dei blocchi per viewport. Si può scegliere di mostrare o nascondere un singolo blocco in base al dispositivo (desktop, tablet, mobile) direttamente dall’editor, senza plugin. I breakpoint sono personalizzabili.
Font Library per tutti i temi. Introdotta in WordPress 6.5 ma riservata ai temi a blocchi, la Font Library è ora disponibile anche per i temi classici. Si gestiscono i font da Aspetto > Font nell’admin, supportando i formati TTF, OTF, WOFF e WOFF2.
CSS per singolo blocco. Nella sezione Avanzate della sidebar di ogni blocco è ora disponibile un campo per aggiungere CSS specifico a quella singola istanza, senza influenzare gli altri elementi del sito. È uno strumento potente, ma va usato con giudizio: più regole CSS sparse per il sito significano più difficoltà nella manutenzione futura.
AI Experiments. WordPress 7.0 introduce funzionalità AI opt-in, ovvero disabilitate di default: generazione automatica dell’estratto, suggerimento dell’alt text per le immagini e qualche altra funzione sperimentale. Non aspettatevi miracoli, sono funzionalità ancora acerbe. La vera infrastruttura AI è pensata per gli sviluppatori, non per gli utenti finali. Almeno per ora.
Le novità per agenzie e webmaster
Il requisito PHP
WordPress 7.0 richiede PHP 7.4 come versione minima, abbandonando il supporto per PHP 7.2 e 7.3. Non è una novità inattesa, ma è il primo requisito da verificare: se il vostro hosting gira ancora su PHP 7.2 o 7.3, non potrete aggiornare a WordPress 7.0. Il sito rimarrà sulla versione 6.9.
La versione raccomandata dal team di sviluppo è PHP 8.3 o superiore. Se avete un contratto di hosting non recente e non avete mai aggiornato la versione PHP, questo è il momento giusto per farlo, indipendentemente da WordPress 7.0: PHP 8.x porta miglioramenti di prestazioni e sicurezza significativi rispetto alle versioni precedenti. Se il vostro host propone ancora PHP 7.2 come default nel 2026, è probabilmente anche il momento di valutare un cambio di hosting.
L’iframed editor e i blocchi custom
WordPress 7.0 fa girare l’editor dei post all’interno di un iframe. Si tratta di un cambiamento tecnico con implicazioni pratiche per chi ha sviluppato blocchi Gutenberg personalizzati: quelli che puntano a selettori CSS globali come .wp-admin o .editor-styles-wrapper, oppure che fanno query sull’intero documento, o che inizializzano librerie JavaScript a livello globale, potrebbero smettere di funzionare correttamente nell’editor.
La buona notizia è che l’enforcement completo dell’iframed editor è stato posticipato alla versione 7.1. Nella 7.0 l’editor viene inserito in un iframe solo quando tutti i blocchi presenti nel contenuto usano l’API version 3 o superiore, quindi nella maggior parte dei siti il problema non si presenterà immediatamente. Ma è un segnale chiaro: chi ha blocchi datati dovrà aggiornarli.
DataViews sostituisce le WP List Tables
L’interfaccia admin di WordPress è rimasta sostanzialmente invariata per anni. Con la 7.0 le schermate Articoli, Pagine e Media vengono ricostruite con DataViews, un sistema moderno che permette filtri, ordinamenti e raggruppamenti senza ricaricare la pagina.
Il problema è che molti plugin intervengono su queste schermate per aggiungere colonne personalizzate, azioni in blocco o modifiche all’interfaccia. Questi plugin rischiano di entrare in conflitto con la nuova struttura. Se gestite siti con plugin di amministrazione personalizzati, column manager o admin theme plugin, vanno testati in staging prima di aggiornare.
Registrazione blocchi solo via PHP
Per chi sviluppa blocchi Gutenberg: la registrazione e il rendering dei blocchi può ora avvenire interamente in PHP, con controlli dell’inspector generati automaticamente. Questo è positivo per la semplicità di sviluppo, ma implica che i blocchi registrati esclusivamente via JavaScript potrebbero avere comportamenti diversi. Se avete blocchi custom sviluppati con un approccio JavaScript-first, vale la pena verificare.
Infrastruttura AI: per sviluppatori, non per utenti
L’Abilities API e i Connectors non sono funzionalità per chi pubblica contenuti, ma fondamenta per chi sviluppa plugin. I Connectors sono accessibili da Impostazioni > Connectors nell’admin e permettono di collegare provider AI esterni (OpenAI, Anthropic o altri) tramite API key. La gestione avviene da un unico punto nell’admin invece di essere dispersa tra diversi plugin. È infrastruttura, non prodotto finito.
Cosa è rimandato a WordPress 7.1
Per chi sta pianificando i propri aggiornamenti, è utile sapere cosa non arriverà con la 7.0:
- L’enforcement completo dell’iframed editor
- Il blocco Tabs, il blocco Playlist e il blocco Dialog
- La registrazione di raccolte di icone di terze parti per il blocco Icons
- Le Core Abilities per la gestione dei post via API
WordPress 7.1 è atteso per agosto 2026, in coincidenza con il WordCamp US.
Compatibilità: cosa rischia di rompersi
Plugin
La prima cosa da sapere è che WordPress mantiene una forte compatibilità con le versioni precedenti: la maggior parte dei plugin costruiti per la serie 6.x continuerà a funzionare. Il rischio riguarda categorie specifiche.
I plugin a rischio più alto sono quelli che intervengono sull’interfaccia amministrativa: plugin con colonne personalizzate nelle liste dei post, estensioni per le azioni in blocco, plugin che modificano l’aspetto dell’ area di amministrazione. Il cambiamento portato da DataViews può creare conflitti con questi strumenti.
Per i page builder più diffusi (Elementor, Divi, Beaver Builder, Bricks) sono attesi aggiornamenti di compatibilità prima del rilascio definitivo. Per i plugin premium più diffusi come Yoast, ACF, WooCommerce, WPML e Gravity Forms, i rispettivi team rilasciano tipicamente gli aggiornamenti di compatibilità entro la prima settimana dal rilascio.
La regola pratica più affidabile rimane questa: i plugin non aggiornati negli ultimi sei mesi sono la principale fonte di problemi durante i major upgrade. Se avete plugin abbandonati o non aggiornati, il problema esiste già oggi, indipendentemente da WordPress 7.0.
Temi
I temi in generale sono meno a rischio dei plugin. Ci sono però due situazioni specifiche da tenere d’occhio.
La prima riguarda i temi classici e la Font Library: questa funzionalità, ora disponibile anche per i temi che non usano il Site Editor, potrebbe interferire con plugin di gestione dei font già installati o con dichiarazioni CSS personalizzate per la tipografia. Vale la pena testarlo.
La seconda riguarda la visibilità dei blocchi per viewport: se il vostro tema usa layout complessi con CSS personalizzato legato ai dispositivi, è utile verificare che le nuove opzioni di visibilità non creino sovrapposizioni indesiderate.
Come prepararsi: la checklist pratica
Prima di aggiornare qualunque sito a WordPress 7.0, questi sono i passi che consigliamo:
Verificate la versione PHP. Andate su Strumenti > Salute del sito nel vostro admin WordPress e cercate la sezione Server. Se la versione PHP è inferiore a 7.4, contattate il vostro hosting prima di fare qualunque altra cosa.
Fate un backup completo. Database e file. Non è negoziabile. Se non avete un sistema di backup automatico, installatene uno prima di procedere.
Testate in staging, non in produzione. Quasi tutti gli hosting moderni offrono un ambiente di staging. Se il vostro non lo fa, è un altro buon motivo per valutare un cambiamento.
Aggiornate plugin e temi prima di aggiornare WordPress. L’ordine conta. Plugin aggiornati hanno più probabilità di essere già compatibili con 7.0.
Aspettate 1-2 settimane dalla release. Le prime segnalazioni di incompatibilità arrivano sempre nelle settimane successive al rilascio, e i rispettivi developer rilasciano le correzioni rapidamente. Chi aspetta qualche giorno si risparmia spesso qualche grattacapo.
