In queste ultime settimane ho seguito con grande attenzione il ciclo di sviluppo di WordPress 7.0, e devo dire che questa release mi sta entusiasmando come poche altre negli ultimi anni. Dopo un 2025 turbolento — tra dispute legali e rallentamenti nello sviluppo — la community WordPress è tornata in carreggiata con quella che è probabilmente la versione più ambiziosa dai tempi dell’introduzione di Gutenberg nel 2018. Ho già scritto un articolo su come prepararsi all’aggiornamento a WordPress 7.0 con la checklist di compatibilità, ma oggi voglio approfondire gli aspetti più tecnici che ogni sviluppatore e sysadmin dovrebbe conoscere.
La Beta 1 è uscita il 20 febbraio 2026, seguita dalla Beta 2 il 26 febbraio con oltre 70 fix e aggiornamenti. La data di rilascio finale è fissata per il 9 aprile 2026, in concomitanza con il WordCamp Asia. Vi mostro in dettaglio le novità più importanti: Post Editor Iframed, Block Visibility basata sul viewport, CSS custom per singolo blocco, gli strumenti AI integrati nel core e molto altro.
Post Editor Sempre Iframed: Cosa Cambia per gli Sviluppatori WordPress 7.0
Questa è una delle novità più impattanti dal punto di vista tecnico. Nella mia esperienza con temi e plugin custom, l’isolamento degli stili è sempre stato un problema. In WordPress 7.0, il post editor sarà sempre eseguito all’interno di un iframe, indipendentemente dalla versione API dei blocchi utilizzati. Fino a WordPress 6.9, l’iframe veniva applicato solo se tutti i blocchi registrati usavano l’API versione 3 o superiore. Ora il comportamento è cambiato: WordPress controlla solo i blocchi effettivamente inseriti nel post.
I vantaggi tecnici dell’editor iframed sono significativi:
- Isolamento degli stili: gli stili CSS dell’admin non influenzano più il contenuto dell’editor e viceversa
- Unità viewport corrette: le unità CSS come vw e vh funzionano correttamente, riferendosi alle dimensioni dell’editor e non dell’intera pagina admin
- Media queries native: niente più workaround fragili per il responsive nell’editor
- Parità visiva: quello che vedi nell’editor corrisponde a ciò che vedrai nel frontend
All’inizio, durante i miei test, non funzionava correttamente perché alcuni blocchi di un plugin che uso facevano riferimento al document globale tramite JavaScript. In un editor iframed, il document e il window dell’iframe sono diversi da quelli della pagina admin principale. La soluzione è creare un ref per accedere al ownerDocument o defaultView relativi. Se avete blocchi custom, vi consiglio di verificare subito la compatibilità aggiornando all’API versione 3.
Block Visibility: Controlli Responsive per Viewport
Questa è una funzionalità che aspettavo da tempo. La Block Visibility era arrivata in WordPress 6.9 con la possibilità di nascondere un blocco dal frontend. In WordPress 7.0 si fa un salto di qualità: arrivano i controlli di visibilità basati sul viewport.
In pratica, potete decidere se mostrare o nascondere specifici blocchi in base alla dimensione dello schermo — mobile, tablet o desktop — direttamente dall’editor. Nella mia esperienza, fino ad ora ho sempre gestito questa cosa con CSS custom e classi nascoste, oppure con plugin dedicati. Avere questa funzionalità nel core rende il design responsive molto più accessibile e pulito.
Per chi gestisce siti WordPress per clienti, come faccio io quotidianamente, questa è una svolta: meno plugin di terze parti, meno codice custom, e un’esperienza utente più intuitiva per chi lavora con l’editor a blocchi.
CSS Custom per Singolo Blocco: Potente ma da Usare con Cautela
Una novità introdotta tramite Gutenberg 22.5 e che arriva in WordPress 7.0 è il supporto al CSS custom per singola istanza di blocco. Nella sidebar delle impostazioni del blocco, sotto Avanzate → Additional CSS, potete ora scrivere CSS specifico per quella singola istanza.
Quando un blocco ha CSS custom associato, viene aggiunta dinamicamente la classe .has-custom-css sia nell’editor che nel frontend. Questo è utile per modifiche one-off — ad esempio aggiungere un’ombra a un singolo bottone — senza dover creare child theme o scrivere selettori CSS complessi.
Detto questo, ho configurato ambienti dove l’uso eccessivo di CSS inline sui blocchi ha creato problemi di manutenibilità. Vi consiglio di usare questa funzionalità con parsimonia: nella maggior parte dei casi, è meglio mantenere gli stili a livello globale tramite theme.json o usare le Block Style Variations per un codebase più pulito. Se vi interessa approfondire l’ottimizzazione delle performance lato CSS, ho scritto anche su come abilitare la compressione Brotli su Nginx per velocizzare il caricamento degli asset.
WP AI Client e Connectors: L’Infrastruttura AI nel Core di WordPress
Qui si entra nel territorio più innovativo di WordPress 7.0. Il WP AI Client porta nel core un layer che permette a plugin e temi di interfacciarsi con modelli AI di qualsiasi provider — OpenAI, Anthropic, Google — attraverso un’interfaccia standardizzata e provider-agnostic.
Non troverete un “AI writer” integrato nel CMS: si tratta delle fondamenta su cui i plugin potranno costruire. L’approccio è “infrastruttura prima, prodotto dopo”. Nella Beta 2 è stata introdotta una novità significativa: la pagina Connectors nel dashboard, accessibile da Settings → Connectors. Da qui potete gestire le connessioni AI esterne in modo centralizzato — aggiungere, eliminare, aggiornare le credenziali dei provider.
L’architettura è estensibile e basata su route, con plugin e temi che possono agganciarsi alla pagina tramite hook come connections-wp-admin-init e le nuove API di registrazione. Se avete già letto il mio articolo sul Model Context Protocol (MCP), saprete che questo standard sta diventando fondamentale per connettere l’AI ai servizi. WordPress 7.0 integra un MCP Adapter ufficiale che traduce le Abilities API nel formato MCP, permettendo ad agenti AI come Claude Desktop o Cursor di scoprire e invocare le funzionalità di WordPress programmaticamente.
Abilities API e MCP Adapter: Come Funzionano Insieme
L’Abilities API, introdotta in WordPress 6.9, crea un registro centrale di capacità, rendendo le funzionalità WordPress scopribili e accessibili ad agenti AI, strumenti di automazione e sviluppatori. L’MCP Adapter si posiziona sopra le Abilities e converte automaticamente le abilities registrate in tools, resources e prompts MCP.
Il risultato è una comunicazione AI bidirezionale: WordPress può chiamare l’AI (tramite WP AI Client) e l’AI può chiamare WordPress (tramite MCP Adapter). Questo trasforma WordPress da CMS “AI-compatible” a piattaforma “AI-native”. Per approfondire come l’AI agentica stia evolvendo, vi rimando al mio articolo sull’Agentic AI e i sistemi multi-agente.
Collaborazione in Tempo Reale: La Fase 3 di Gutenberg
WordPress 7.0 segna l’ingresso ufficiale nella Fase 3 del progetto Gutenberg: la Collaborazione. Più utenti possono ora modificare lo stesso post o pagina simultaneamente, con sincronizzazione dei dati e note in tempo reale. Durante il periodo beta, la collaborazione real-time è opt-in per raccogliere feedback più ampi.
Le Notes, introdotte in 6.9, ricevono miglioramenti significativi: sincronizzazione in tempo reale, shortcut da tastiera, targeting di frammenti specifici di testo, menzioni @utente con notifiche, e risposte annidate. Per il periodo beta, WordPress utilizza un provider di sincronizzazione basato su HTTP polling, con opzioni per plugin o hosting provider di implementare il supporto WebSocket.
Nuovi Blocchi, Design Tools e Altre Novità
Oltre alle novità principali, WordPress 7.0 porta con sé una serie di miglioramenti che nella mia esperienza quotidiana fanno la differenza:
- Nuovi blocchi core: Icon Block, Breadcrumbs Block, Grid Block stabilizzato per la produzione
- Cover Block con video embed: sfondi video nelle sezioni, finalmente nativi
- Navigation Block migliorato: gestione menu più intuitiva con meno passaggi
- Font Library per tutti i temi: gestione font installati abilitata universalmente
- Client-side media processing: il ridimensionamento e la compressione delle immagini avvengono nel browser prima dell’upload
- View Transitions nell’admin: transizioni fluide tra le schermate del pannello di amministrazione
- React 19 upgrade: miglioramenti di performance per l’editor a blocchi
- Spotlight Mode e Isolated Editor Mode: isolamento del contenuto per pattern e template parts
- PHP-only block registration: blocchi generati server-side con auto-registrazione all’API dei blocchi
Se gestite siti con molte immagini, la combinazione del client-side media processing con le tecniche che ho descritto nel mio articolo su come ottimizzare le immagini su WordPress con WebP, AVIF e Lazy Load vi darà un boost significativo nelle performance.
Requisiti Minimi e Come Testare WordPress 7.0 Beta
Prima di aggiornare, verificate i requisiti:
- PHP minimo 7.4: il supporto per PHP 7.2 e 7.3 viene ufficialmente eliminato. Il team raccomanda PHP 8.3 o superiore per le migliori performance
- Ambiente di test: mai installare la beta su un sito di produzione
Per testare la Beta 2, avete diverse opzioni:
- WordPress Beta Tester plugin: installate il plugin, selezionate il canale “Bleeding edge” e lo stream “Beta/RC Only”
- WP-CLI: eseguite
wp core update --version=7.0-beta2 - WordPress Playground: testate direttamente nel browser senza alcun setup
Nella mia esperienza, la cosa migliore è creare un ambiente di staging dedicato. Se usate Plesk, ho configurato ambienti di test in pochi minuti seguendo la procedura che descrivo nell’articolo su come ottimizzare PHP-FPM e OPcache su Plesk. Vi consiglio anche di fare prima un audit completo dei plugin per verificare la compatibilità con la nuova versione.
FAQ
Quando esce WordPress 7.0 in versione stabile?
La data di rilascio ufficiale di WordPress 7.0 è il 9 aprile 2026, in concomitanza con il WordCamp Asia. Prima di quella data ci saranno ulteriori beta e almeno una Release Candidate (RC1 prevista per il 19 marzo). Non installate le versioni beta o RC su siti di produzione.
I miei plugin e temi funzioneranno con WordPress 7.0?
Dipende. Il cambiamento più impattante è l’editor post sempre iframed: se i vostri blocchi custom fanno riferimento al document o window globale, potrebbero richiedere aggiornamenti. Controllate che tutti i blocchi usino la API versione 3 e testate su un ambiente di staging prima dell’aggiornamento. Anche il requisito minimo di PHP 7.4 potrebbe escludere siti su hosting datati.
Posso usare le funzionalità AI di WordPress 7.0 subito?
Il WP AI Client e la pagina Connectors forniscono l’infrastruttura, non funzionalità AI pronte all’uso. Dovrete comunque configurare le credenziali di un provider AI (OpenAI, Anthropic, Google) e utilizzare plugin che sfruttano queste API. L’AI Experiments plugin è un buon punto di partenza per esplorare le possibilità.
Qual è la versione PHP consigliata per WordPress 7.0?
Il minimo è PHP 7.4, ma il core team raccomanda fortemente PHP 8.3 o superiore. Il salto di performance tra PHP 7.4 e 8.3 è notevole su ogni caricamento di pagina. Se state aggiornando PHP per la compatibilità con 7.0, non fermatevi al minimo: puntate almeno a PHP 8.1 o superiore.
La Block Visibility sostituisce i plugin responsive come Block Visibility for Gutenberg?
La funzionalità core copre i controlli base di visibilità per viewport (mostra/nascondi per mobile, tablet, desktop). I plugin dedicati offrono tipicamente condizioni più avanzate (ruoli utente, orari, geolocalizzazione). Per la maggior parte degli usi, la funzionalità nativa sarà sufficiente e vi permetterà di eliminare un plugin.
Conclusione: Prepararsi a WordPress 7.0 Beta e al Rilascio
WordPress 7.0 è davvero una release che cambia le carte in tavola. Le novità per sviluppatori — dal post editor iframed alla Block Visibility, dal CSS custom per blocco all’infrastruttura AI con WP AI Client e MCP Adapter — segnano un passo avanti significativo per la piattaforma. Nella mia esperienza, ogni major release richiede preparazione, e questa non fa eccezione.
Il mio consiglio è semplice: create un ambiente di staging, installate la Beta 2, testate i vostri temi e plugin, verificate la versione PHP del server e riportate eventuali bug. Il periodo tra ora e il rilascio del 9 aprile è cruciale per la stabilità della versione finale. Se avete dubbi sulla procedura di migrazione o aggiornamento, vi rimando alla mia guida su come migrare un sito senza downtime.
Avete già testato la beta? Quali novità vi interessano di più? Fatemelo sapere nei commenti — sono curioso di sapere come sta andando nei vostri ambienti di test.