Se gestisci siti WordPress come me, probabilmente hai già sentito il fermento intorno a WordPress 7.0. La Beta 1 è stata rilasciata il 20 febbraio 2026 e la versione finale è prevista per il 9 aprile 2026, in concomitanza con il WordCamp Asia. Si tratta dell’aggiornamento più ambizioso degli ultimi anni, e nella mia esperienza è fondamentale prepararsi prima che arrivi in produzione, non dopo.
In questo articolo vi mostro come mi sto preparando all’aggiornamento a WordPress 7.0: analizzeremo insieme le novità principali — dalla collaborazione in tempo reale alla nuova Abilities API, dal CSS per blocco singolo al WP AI Client — e vi condividerò la mia checklist operativa per garantire la compatibilità di temi e plugin. Ho già iniziato i test su ambiente di staging e voglio risparmiarvi le difficoltà che ho incontrato.
Se vi siete persi le basi, ho scritto una guida su come configuro WordPress dopo l’installazione che resta un ottimo punto di partenza. Ma ora concentriamoci su ciò che cambia con la 7.0.
Cosa Porta WordPress 7.0: Le Novità Principali
WordPress 7.0 rappresenta il lancio ufficiale della Fase 3 del progetto Gutenberg, incentrata su collaborazione e workflow. Dopo un 2025 rallentato dalle vicende legali e dalla pausa nelle contribuzioni di Automattic, il 2026 segna il ritorno alla cadenza di tre major release annuali: la 7.0 in primavera, la 7.1 ad agosto e la 7.2 a dicembre.
Ecco le feature che ho trovato più significative durante i miei test sulla Beta 1:
Collaborazione in Tempo Reale
La funzionalità che tutti aspettavamo: più utenti possono modificare lo stesso post o pagina contemporaneamente, vedendo le modifiche degli altri in tempo reale con sincronizzazione dei dati. WordPress 6.9 aveva introdotto i Notes per i commenti sui blocchi; la 7.0 fa un salto enorme con un vero sistema di co-editing stile Google Docs.
Il sistema utilizza un provider di sincronizzazione basato su HTTP polling come default, con la possibilità per hosting e plugin di aggiungere supporto WebSocket per prestazioni migliori. All’inizio non funzionava bene sul mio shared hosting di test — la collaborazione in tempo reale richiede connessioni persistenti che gli hosting condivisi economici potrebbero non supportare adeguatamente.
Abilities API: WordPress Diventa AI-Ready
Questa è la novità che, secondo me, cambierà di più l’ecosistema. L’Abilities API, introdotta con WordPress 6.9 e potenziata nella 7.0, fornisce un modo standardizzato per registrare e scoprire unità di funzionalità all’interno di un sito WordPress.
In pratica, ogni plugin, tema o componente core può descrivere le proprie “abilities” (capacità) in un formato machine-readable e human-friendly. Questo significa che strumenti di automazione, agenti AI e altri plugin possono “chiedere” al sito cosa sa fare e interagire con queste funzionalità in modo prevedibile e sicuro.
L’API si compone di tre elementi principali:
- PHP API per registrare, gestire ed eseguire le abilities tramite
wp_register_ability() - REST API automatica sotto il namespace
wp-abilities/v1, senza sforzo aggiuntivo per lo sviluppatore - Hook di integrazione come
wp_abilities_api_init,wp_before_execute_abilityewp_after_execute_ability
Ogni ability ha input/output definiti tramite JSON Schema, permission callback per il controllo degli accessi e una callback di esecuzione. Se avete già familiarità con l’audit dei plugin, come ho descritto nella mia guida all’audit dei plugin WordPress, capirete l’importanza di avere permessi granulari.
WP AI Client e MCP Adapter
WordPress 7.0 introduce anche il WP AI Client, un layer nel core che permette di interfacciarsi con modelli AI di qualsiasi provider (OpenAI, Google, Anthropic) in modo provider-agnostic. Non è un “AI writer” integrato, ma la base infrastrutturale per sviluppare strumenti AI-powered.
Il MCP Adapter (Model Context Protocol) traduce le abilities registrate nel protocollo creato da Anthropic, consentendo ad agenti AI come Claude e Cursor di scoprire e utilizzare le funzionalità del sito direttamente. È una visione lungimirante: WordPress non si limita ad aggiungere feature AI, ma costruisce l’infrastruttura affinché l’AI possa interagire con i siti dall’esterno.
CSS per Blocco Singolo: Personalizzazione Granulare
Una novità che ho subito apprezzato: con Gutenberg 22.5, integrato in WordPress 7.0, è possibile aggiungere CSS personalizzato a singole istanze di blocco. Lo trovate in Avanzate → CSS Aggiuntivo nel pannello laterale del blocco.
Quando un blocco ha CSS personalizzato, viene aggiunta dinamicamente la classe .has-custom-css sia nell’editor che nel frontend. È molto utile per modifiche one-off, ma vi avverto: può creare problemi di manutenzione se ne abusate. Nella maggior parte dei casi, preferisco mantenere gli stili a livello globale o usare le block style variations.
Per i temi, il sistema dei per-block stylesheets tramite wp_enqueue_block_style() rimane l’approccio consigliato per CSS specifico per tipo di blocco, poiché carica il CSS solo quando il blocco è effettivamente presente nella pagina. Per chi lavora sulle performance — come ho descritto nell’articolo su come ottimizzo le immagini su WordPress — questo approccio è decisamente preferibile.
Altre Novità Importanti
- Nuovi blocchi: Icons, Breadcrumbs e un blocco Heading rinnovato
- Cover block con supporto per sfondi video embed
- Grid block responsive-enabled
- Controlli di visibilità viewport: nascondere o mostrare blocchi in base alla dimensione dello schermo
- Client-side media processing: ridimensionamento e compressione immagini lato browser
- Font Library abilitata per tutti i temi
- View transitions nell’admin per transizioni fluide tra schermate
- DataViews con nuovo layout activity e supporto per tipi di terze parti
- Post editor sempre in iframe, per separare stili UI da stili blocco/tema
- Supporto text indent e textColumns nel blocco Paragrafo
- CodeMirror aggiornato alla versione 5.65.40
Requisiti Minimi di WordPress 7.0: Cosa Verificare Subito
Prima di pensare alle novità, assicuratevi che il vostro server sia compatibile. Ecco i requisiti aggiornati:
- PHP: minimo 7.4 (consigliato 8.3+). Il supporto a PHP 7.2 e 7.3 viene ufficialmente eliminato
- MySQL: 8.0 o superiore, oppure MariaDB 10.6 o superiore
Se siete ancora su PHP 7.2 o 7.3, il sito resterà sul branch WordPress 6.9 ricevendo solo aggiornamenti di sicurezza ma nessuna nuova feature. Nella mia esperienza su Plesk, aggiornare PHP è questione di pochi clic — se vi serve una guida, ho scritto su come ottimizzo PHP-FPM e OPcache su Plesk.
La Mia Checklist di Compatibilità per Temi e Plugin WordPress 7.0
Ecco la procedura che sto seguendo sui miei siti. Ve la condivido step-by-step:
Step 1: Crea un Ambiente di Staging
Non testate mai su produzione. Io uso un sottodominio dedicato con una copia completa del sito. Se usate Plesk, potete clonare il sito in pochi minuti. Altrimenti, la mia guida su come migro un sito su nuovo hosting senza downtime contiene procedure utili anche per creare ambienti di test.
Step 2: Verifica i Requisiti Server
- Controlla la versione PHP: deve essere almeno 7.4, idealmente 8.2+
- Verifica MySQL (≥ 8.0) o MariaDB (≥ 10.6)
- Assicurati che il server supporti connessioni persistenti se vuoi la collaborazione in tempo reale
Step 3: Aggiorna Tutto Prima di Testare
- Aggiorna WordPress all’ultima 6.9.1
- Aggiorna tutti i plugin all’ultima versione
- Aggiorna il tema all’ultima versione
- Esegui un cleanup del database per eliminare transient e revisioni inutili
Step 4: Installa WordPress 7.0 Beta su Staging
Il modo più semplice è usare il plugin WordPress Beta Tester. Installatelo sullo staging, selezionate il canale “Bleeding edge” e aggiornate. In alternativa, scaricate la Beta direttamente da wordpress.org.
Step 5: Test Sistematico dei Plugin
Per ogni plugin attivo, verificate:
- Funziona senza errori o warning PHP?
- Le pagine generate dal plugin si caricano correttamente?
- Le funzionalità AJAX funzionano?
- Il plugin è compatibile con il post editor in iframe?
- Eventuali custom block funzionano con la nuova versione di Gutenberg?
Un consiglio pratico: attivate WP_DEBUG e WP_DEBUG_LOG nel wp-config.php dello staging per catturare ogni errore:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Step 6: Test del Tema
Verificate attentamente:
- Il layout è corretto su tutte le pagine (home, archivi, singoli post, pagine statiche)?
- I nuovi blocchi (Icons, Breadcrumbs) si integrano bene con il design?
- Il post editor in iframe non crea conflitti con CSS personalizzati del tema?
- La Font Library, ora abilitata per tutti i temi, non crea duplicazioni di font?
- Le view transitions nell’admin funzionano senza glitch?
Step 7: Verifica la Sicurezza
Un aggiornamento major è il momento giusto per rivedere la sicurezza complessiva. Ho scritto una guida dettagliata su come metto in sicurezza WordPress da attacchi brute force che vi consiglio di seguire in parallelo.
Step 8: Backup Completo Prima dell’Aggiornamento
Sembra banale, ma è vitale. Fate un backup completo di file e database prima di aggiornare la produzione. Se usate Plesk con backup remoti, la mia guida su backup remoto S3 con Wasabi può aiutarvi a configurare un sistema affidabile.
Come Testo l’Abilities API su Staging
Per chi sviluppa plugin o vuole capire come funziona l’Abilities API, ecco un esempio pratico che ho testato. Registrare una ability è sorprendentemente semplice:
add_action( 'wp_abilities_api_init', function() {
wp_register_ability( 'mio-plugin/conta-post', array(
'name' => 'Conta i Post',
'description' => 'Restituisce il numero di post pubblicati',
'category' => 'content',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'post_type' => array( 'type' => 'string' )
)
),
'callback' => function( $input ) {
$count = wp_count_posts( $input['post_type'] ?? 'post' );
return array( 'count' => $count->publish );
}
));
});
Una volta registrata, questa ability è automaticamente disponibile via REST API all’endpoint /wp-json/wp-abilities/v1/abilities/mio-plugin/conta-post. Potete testarla con curl usando Application Passwords per l’autenticazione.
Problemi Comuni che Ho Incontrato nei Test
Durante i miei test sulla Beta 1, ho riscontrato alcuni problemi che vale la pena condividere:
- Plugin con block API v2: alcuni plugin più datati forzavano il post editor a non usare l’iframe. Con la 7.0 l’iframe è sempre attivo, e questo può causare problemi di stile
- CSS personalizzato nel Customizer: se avete CSS nel vecchio Customizer, verificate che funzioni ancora correttamente con le nuove view transitions
- Unit test failures: la Beta 1 stessa è stata ritardata di un giorno a causa di fallimenti nei test relativi al WP REST autosave controller. Questo suggerisce che l’area della collaborazione real-time potrebbe avere ancora qualche spigolo
- Hosting condiviso: la collaborazione in tempo reale non funziona al meglio su shared hosting economici che non supportano connessioni persistenti
Timeline WordPress 7.0: Date da Segnare
- 20 febbraio 2026: Beta 1 rilasciata
- Febbraio-marzo 2026: ulteriori beta e Release Candidate
- 9 aprile 2026: release finale al WordCamp Asia
- 19 agosto 2026 (tentativo): WordPress 7.1
- Dicembre 2026 (tentativo): WordPress 7.2
FAQ
Quando esce WordPress 7.0 e devo aggiornare subito?
La versione finale di WordPress 7.0 è prevista per il 9 aprile 2026. Il mio consiglio è di non aggiornare il primo giorno: testate prima su staging, aspettate qualche giorno per la community di segnalare eventuali bug critici, e poi procedete. Io di solito aspetto la prima minor release (7.0.1) per i siti più critici.
La mia versione PHP è compatibile con WordPress 7.0?
WordPress 7.0 richiede PHP 7.4 come minimo e raccomanda PHP 8.3 o superiore. Se siete ancora su PHP 7.2 o 7.3, il vostro sito non riceverà l’aggiornamento automatico e resterà sulla 6.9 con soli fix di sicurezza. Verificate subito la vostra versione PHP da Strumenti → Salute del sito nella dashboard WordPress.
Cos’è l’Abilities API e perché è importante?
L’Abilities API è un sistema che permette a plugin, temi e core di registrare le proprie funzionalità in un formato standardizzato e leggibile dalle macchine. Questo rende WordPress “comprensibile” da agenti AI, tool di automazione e altri plugin, aprendo la strada a integrazioni intelligenti senza codice personalizzato per ogni servizio.
Il CSS per blocco singolo sostituisce i per-block stylesheets dei temi?
No, sono due cose diverse. Il CSS per blocco singolo (Additional CSS) permette di aggiungere stili CSS a una specifica istanza di un blocco in un post. I per-block stylesheets del tema, invece, definiscono stili per tutti i blocchi di un determinato tipo e vengono caricati solo quando quel tipo di blocco è presente nella pagina. Per la manutenibilità, consiglio di preferire sempre gli stili a livello di tema.
Devo preoccuparmi per la compatibilità dei miei plugin?
Sì, soprattutto se utilizzate plugin che creano blocchi personalizzati o che interagiscono con l’editor. Il passaggio al post editor sempre in iframe è il cambiamento che più probabilmente causerà problemi. Testate tutto su staging con WP_DEBUG attivo e contattate gli sviluppatori dei plugin se trovate incompatibilità.
Conclusione
L’aggiornamento a WordPress 7.0 è uno dei più significativi degli ultimi anni. La collaborazione in tempo reale, l’Abilities API, il CSS per blocco singolo, il WP AI Client e il rinnovamento dell’admin rappresentano un cambio di paradigma per la piattaforma. Ma come ogni grande aggiornamento, richiede preparazione.
La mia checklist di compatibilità per temi e plugin vi aiuterà ad affrontare la transizione senza sorprese. Iniziate oggi a testare: create lo staging, installate la Beta, attivate il debug e verificate ogni componente. Aprile arriva prima di quanto pensiate.
Avete già testato la Beta 1? Avete riscontrato problemi con qualche plugin specifico? Scrivetelo nei commenti: è il modo migliore per aiutare tutta la community a prepararsi!