Nelle ultime settimane ho passato diverse ore a testare le beta di WordPress 7.0 sui miei ambienti di staging, e vi confesso che questa release è probabilmente la più impattante per gli sviluppatori di plugin dal passaggio a Gutenberg. Con il rilascio della Beta 5 a marzo 2026 e la Release Candidate 1 il 19 marzo, il quadro è ormai chiaro: ci sono breaking changes reali che richiedono interventi immediati, e soprattutto c’è l’integrazione dell’AI direttamente nel core che cambia le regole del gioco.
Se sviluppate plugin WordPress — o anche solo li mantenete per i vostri clienti — questo articolo è la guida che avrei voluto avere quando ho iniziato a migrare i miei progetti. Vi porto attraverso ogni cambiamento critico, con codice reale e soluzioni testate. La release finale è prevista per il 9 aprile 2026, quindi il tempo per prepararsi è adesso.
In un precedente articolo sulla Beta di WordPress 7.0 avevo già anticipato alcune novità. Oggi entriamo nel dettaglio tecnico dei breaking changes e del migration path completo.
WP AI Client: l’AI Entra nel Core di WordPress
La novità più significativa di WordPress 7.0 è senza dubbio il WP AI Client, un’API provider-agnostic per comunicare con modelli AI generativi direttamente dal core. La proposta di merge è stata pubblicata a febbraio 2026 su Make WordPress Core, e dopo settimane di iterazioni nelle beta, il sistema è ora stabile.
Il punto di ingresso principale per gli sviluppatori è la funzione wp_ai_client_prompt(), che restituisce un Prompt_Builder_With_WP_Error. Ecco come si usa nella pratica:
// Esempio base: generare testo con WP AI Client
$response = wp_ai_client_prompt()
->set_model( 'default' )
->set_system_prompt( 'Sei un assistente per blog WordPress.' )
->add_user_message( 'Genera una meta description per un articolo su PHP 8.4' )
->send();
if ( is_wp_error( $response ) ) {
error_log( 'AI Client error: ' . $response->get_error_message() );
} else {
$text = $response->get_text();
}Quello che rende questa API davvero potente è che è completamente agnostica rispetto al provider. Potete chiamare OpenAI, Anthropic (Claude) o Google Gemini con lo stesso codice — la scelta del provider è gestita dall’utente nella nuova schermata Connectors dell’admin.
Attenzione: il pacchetto standalone è deprecato
Se stavate usando il pacchetto wp-ai-client come plugin separato durante lo sviluppo, sappiate che su WordPress 7.0+ l’infrastruttura PHP del SDK esterno viene disabilitata automaticamente — il core lo gestisce nativamente. I REST API endpoints e la JavaScript API del pacchetto restano attivi perché non sono ancora nel core, ma la migrazione è inevitabile.
Nel mio plugin AI Publisher WP, ho già iniziato a predisporre un layer di compatibilità che rileva la versione di WordPress e usa l’API nativa quando disponibile. Ve lo consiglio caldamente.
La Connectors API: Gestione Centralizzata dei Servizi Esterni
WordPress 7.0 introduce la Connectors API, un framework per registrare e gestire connessioni a servizi esterni con focus iniziale sui provider AI. Questo significa gestione centralizzata delle API key, provider discovery e una UI admin dedicata sotto Impostazioni → Connectors.
L’hook principale per registrare nuovi tipi di connector è wp_connectors_init:
add_action( 'wp_connectors_init', function( $registry ) {
// I provider AI registrati con WP AI Client
// ottengono il connector automaticamente.
// Per servizi custom:
$registry->register( 'my-custom-service', array(
'label' => 'My Custom API',
'description' => 'Connessione al servizio XYZ',
'fields' => array(
'api_key' => array(
'label' => 'API Key',
'type' => 'secret',
),
),
) );
} );Limitazione importante per la 7.0: nella release iniziale, la schermata Connectors supporta solo i 3 provider ufficiali (OpenAI, Anthropic, Google) con configurazione hardcoded. L’estensibilità completa per provider di terze parti è pianificata per WordPress 7.1. Tuttavia, l’hook connections-wp-admin-init e le API di registrazione sono già disponibili per chi vuole prepararsi.
Se state sviluppando un plugin AI, il mio consiglio è: registrate il vostro provider con il WP AI Client e il connector verrà creato automaticamente con i metadati corretti. Non serve codice aggiuntivo.
DataViews: il Breaking Change che Rompe i Plugin di Admin
Questo è il cambiamento che mi ha dato più grattacapi durante i test. Il componente DataViews — usato per le liste di post, pagine e altri contenuti nell’admin — ha subito una modifica strutturale alla configurazione del raggruppamento.
Prima (WordPress 6.9)
const view = {
type: 'table',
groupByField: 'status'
};Dopo (WordPress 7.0)
const view = {
type: 'table',
groupBy: {
field: 'status',
direction: 'asc',
showLabel: true
}
};Il vecchio groupByField (stringa) è stato sostituito da un oggetto groupBy che supporta field, direction e label visibility. Qualsiasi plugin che personalizza le liste nell’admin usando DataViews deve aggiornare questa sintassi, altrimenti si rompe silenziosamente.
Come ho scritto nella mia guida alla roadmap di WordPress 7.0, la Phase 3 Collaboration porta con sé molti cambiamenti strutturali, e DataViews è uno dei più impattanti.
PHP-Only Blocks: Addio JavaScript Obbligatorio
Questa è stata una delle novità più apprezzate dalla community, e devo dire che nella mia esperienza semplifica enormemente lo sviluppo. WordPress 7.0 permette di registrare blocchi interamente in PHP, senza una singola riga di JavaScript:
register_block_type( 'mio-plugin/info-box', array(
'supports' => array(
'autoRegister' => true,
),
'attributes' => array(
'title' => array(
'type' => 'string',
'default' => 'Titolo',
),
'showBorder' => array(
'type' => 'boolean',
'default' => true,
),
'columns' => array(
'type' => 'integer',
'default' => 2,
),
),
'render_callback' => function( $attributes ) {
$border = $attributes['showBorder'] ? ' style="border:1px solid #ccc"' : '';
return sprintf(
'<div class="info-box"%s><h3>%s</h3></div>',
$border,
esc_html( $attributes['title'] )
);
},
) );Con 'autoRegister' => true, il blocco appare nell’editor e WordPress genera automaticamente gli Inspector Controls per i tipi di attributo supportati: string, integer, boolean e enum. Niente più build chain React solo per un blocco semplice.
Block Visibility e Responsive Styling Controls
WordPress 7.0 introduce i Block Visibility controls nativi: ogni blocco può ora essere mostrato o nascosto in base alla dimensione dello schermo, direttamente dall’editor. Per gli sviluppatori di plugin che offrivano questa funzionalità tramite plugin dedicati (e ce ne sono decine), questo significa potenziale conflitto.
Il mio consiglio: verificate se il vostro plugin di block visibility usa hook o filtri che ora sono gestiti dal core. Se sovrapponete la stessa funzionalità, rischiate comportamenti imprevedibili. Nella mia esperienza, la soluzione migliore è rendere il vostro plugin consapevole della versione di WordPress e disabilitare i controlli duplicati quando il core li fornisce nativamente.
Requisiti PHP Aggiornati e Compatibilità
WordPress 7.0 alza il requisito minimo di PHP a 7.4, abbandonando ufficialmente il supporto per PHP 7.2 e 7.3. Se gestite server come faccio io con Plesk Obsidian, questo non dovrebbe essere un problema — PHP 8.3 è lo standard ormai. Ma se avete clienti su hosting condivisi datati, è il momento di forzare l’aggiornamento.
Per verificare la compatibilità del vostro plugin con PHP 7.4+, usate PHPCompatibility con phpcs:
# Installare PHPCompatibility
composer require --dev phpcompatibility/php-compatibility
# Verificare compatibilità
phpcs --standard=PHPCompatibility --runtime-set testVersion 7.4- mio-plugin/Migration Path Completo: la Mia Checklist Operativa
Dopo aver migrato tre plugin ai cambiamenti di WordPress 7.0, ho consolidato questa checklist che uso su ogni progetto:
- Ambiente di test: create un ambiente staging con WordPress 7.0 Beta 5 o RC1. Usate WordPress Beta Tester o WP-CLI:
wp core update --version=7.0-RC1 - Audit PHP: eseguite phpcs con PHPCompatibility per identificare codice incompatibile con PHP 7.4+
- DataViews: cercate nel vostro codice ogni occorrenza di
groupByFielde sostituitela con il nuovo oggettogroupBy - Editor iframe: verificate che i vostri blocchi non facciano riferimento al
documentglobale in JavaScript — l’editor iframed (puntato a 7.1 ma già attivo nel plugin Gutenberg) isola gli stili - WP AI Client: se usate il pacchetto standalone, pianificate la migrazione all’API nativa del core
- Connectors API: se il vostro plugin gestisce connessioni a servizi esterni, valutate l’integrazione con la nuova API
- PHP-only blocks: considerate la migrazione dei blocchi semplici a
autoRegisterper eliminare dipendenze JavaScript - Block Visibility: verificate conflitti con i nuovi controlli responsive nativi
- Test automatizzati: eseguite la vostra test suite su WordPress 7.0 — i test PHPUnit con WP_UnitTestCase funzionano senza modifiche
- Field Guide: consultate la Field Guide ufficiale pubblicata con la RC1 per la lista completa delle funzioni deprecate
Impatto sull’Ecosistema Plugin: Cosa Aspettarsi
Dalla mia analisi delle beta, i plugin più a rischio di incompatibilità sono:
- Plugin che modificano le liste post/pagine: il cambio DataViews è il rischio più alto
- Plugin di Block Visibility: conflitto diretto con la funzionalità nativa
- Plugin AI: quelli che usano il pacchetto
wp-ai-clientstandalone devono migrare - Plugin con blocchi API version 1-2: console warnings attivi da WP 6.9, upgrade a version 3 raccomandato
- Plugin che accedono al DOM globale nell’editor: l’editor iframed (già nel plugin Gutenberg) rompe i riferimenti al
document
Se avete sviluppato plugin seguendo le best practices che ho descritto nella guida al Vulnerability Disclosure Program, avrete già una struttura di test che facilita questa transizione.
La Mia Esperienza con la Migrazione
Vi racconto brevemente come è andata con il mio plugin. All’inizio non funzionava il pannello di configurazione AI perché cercavo di registrare un connector personalizzato sulla schermata Connectors — solo per scoprire che l’estensibilità di terze parti è prevista per la 7.1. La soluzione è stata mantenere la mia pagina settings per ora e predisporre il codice per la migrazione futura.
Il secondo problema è stato il DataViews: avevo una vista personalizzata nel Content Audit che usava groupByField. Il fix è stato banale (5 minuti), ma senza test l’avrei scoperto solo in produzione. Questo conferma quanto sia importante testare su staging prima dell’aggiornamento.
Come ho già raccomandato nella mia checklist di compatibilità per WordPress 7.0, il testing preventivo è la chiave per evitare sorprese il giorno del rilascio.
FAQ
Quando esce WordPress 7.0 e quali sono le date chiave per gli sviluppatori?
La release finale di WordPress 7.0 è prevista per il 9 aprile 2026. La Release Candidate 1 è uscita il 19 marzo 2026 insieme alla Field Guide ufficiale con tutti i Dev Notes. Vi consiglio di testare i vostri plugin almeno sulla RC1, perché a quel punto le API sono congelate e non ci saranno più breaking changes.
Il mio plugin smette di funzionare con WordPress 7.0 se usa groupByField nelle DataViews?
Non smetterà di funzionare completamente, ma il raggruppamento nelle liste admin non funzionerà più correttamente. Il vecchio groupByField (stringa) è stato sostituito dall’oggetto groupBy con proprietà field, direction e showLabel. La migrazione è semplice ma necessaria. Cercate tutte le occorrenze nel vostro codice JavaScript e aggiornate la sintassi.
Devo riscrivere il mio plugin AI per usare il WP AI Client del core?
Non immediatamente, ma è fortemente consigliato. Il WP AI Client offre un’API unificata che funziona con qualsiasi provider configurato dall’utente. Se il vostro plugin usa connessioni dirette a un singolo provider, potete mantenere il codice esistente. Ma se usavate il pacchetto standalone wp-ai-client, l’infrastruttura PHP viene disabilitata su WP 7.0+ e dovrete migrare all’API nativa wp_ai_client_prompt().
I blocchi PHP-only funzionano anche con il Site Editor o solo nel Post Editor?
I blocchi registrati con 'autoRegister' => true funzionano in tutti i contesti dell’editor: Post Editor, Site Editor e Widget Editor. WordPress genera automaticamente gli Inspector Controls per gli attributi di tipo string, integer, boolean e enum. Tuttavia, per blocchi complessi con interazioni avanzate lato client, il JavaScript resta necessario.
Cosa succede se il mio hosting usa ancora PHP 7.2 o 7.3?
WordPress 7.0 non si installerà o aggiornerà su versioni di PHP inferiori a 7.4. Il sistema di aggiornamento automatico bloccherà l’upgrade. Dovete aggiornare PHP prima di procedere. Se gestite i server con Plesk e WP Toolkit, il cambio versione PHP richiede pochi click. Su hosting condivisi, contattate il provider.
Conclusione
WordPress 7.0 è una release che segna un punto di svolta per l’ecosistema: l’AI entra nel core con il WP AI Client e la Connectors API, i blocchi PHP-only eliminano la barriera JavaScript per i casi semplici, e i breaking changes nelle DataViews richiedono attenzione immediata da parte di chi sviluppa plugin per l’admin.
Il mio consiglio principale è uno solo: testate adesso. Non aspettate il 9 aprile. Installate la RC1 su un ambiente di staging, eseguite i vostri plugin e correggete quello che si rompe. La Field Guide ufficiale su Make WordPress Core è la vostra risorsa definitiva per ogni dettaglio tecnico.
Se avete domande sulla migrazione dei vostri plugin o volete condividere la vostra esperienza con i breaking changes, lasciate un commento qui sotto. E se state esplorando come l’AI si integra con WordPress a livello di architettura, vi consiglio di leggere il mio articolo su WordPress AI nel Core 2026 per il quadro completo.