{"id":1568,"date":"2026-03-20T10:07:40","date_gmt":"2026-03-20T09:07:40","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-breaking-changes-api-ai-integration-migration-plugin-developers\/"},"modified":"2026-03-20T10:07:40","modified_gmt":"2026-03-20T09:07:40","slug":"wordpress-7-breaking-changes-api-ai-integration-migration-plugin-developers","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-breaking-changes-api-ai-integration-migration-plugin-developers\/","title":{"rendered":"Come Affronto i Breaking Changes di WordPress 7.0 per Plugin: API Changes, AI Integration e Migration Path Completo per Sviluppatori"},"content":{"rendered":"

Nelle ultime settimane ho passato diverse ore a testare le beta di WordPress 7.0<\/strong> sui miei ambienti di staging, e vi confesso che questa release \u00e8 probabilmente la pi\u00f9 impattante per gli sviluppatori di plugin dal passaggio a Gutenberg. Con il rilascio della Beta 5<\/em> a marzo 2026 e la Release Candidate 1<\/em> il 19 marzo, il quadro \u00e8 ormai chiaro: ci sono breaking changes reali che richiedono interventi immediati, e soprattutto c’\u00e8 l’integrazione dell’AI direttamente nel core che cambia le regole del gioco.<\/p>\n

Se sviluppate plugin WordPress \u2014 o anche solo li mantenete per i vostri clienti \u2014 questo articolo \u00e8 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 \u00e8 prevista per il 9 aprile 2026<\/strong>, quindi il tempo per prepararsi \u00e8 adesso.<\/p>\n

In un precedente articolo sulla Beta di WordPress 7.0<\/a> avevo gi\u00e0 anticipato alcune novit\u00e0. Oggi entriamo nel dettaglio tecnico dei breaking changes e del migration path completo.<\/p>\n

WP AI Client: l’AI Entra nel Core di WordPress<\/h2>\n

La novit\u00e0 pi\u00f9 significativa di WordPress 7.0 \u00e8 senza dubbio il WP AI Client<\/strong>, un’API provider-agnostic per comunicare con modelli AI generativi direttamente dal core. La proposta di merge \u00e8 stata pubblicata a febbraio 2026 su Make WordPress Core, e dopo settimane di iterazioni nelle beta, il sistema \u00e8 ora stabile.<\/p>\n

Il punto di ingresso principale per gli sviluppatori \u00e8 la funzione wp_ai_client_prompt()<\/code>, che restituisce un Prompt_Builder_With_WP_Error<\/em>. Ecco come si usa nella pratica:<\/p>\n

\/\/ Esempio base: generare testo con WP AI Client\n$response = wp_ai_client_prompt()\n    ->set_model( 'default' )\n    ->set_system_prompt( 'Sei un assistente per blog WordPress.' )\n    ->add_user_message( 'Genera una meta description per un articolo su PHP 8.4' )\n    ->send();\n\nif ( is_wp_error( $response ) ) {\n    error_log( 'AI Client error: ' . $response->get_error_message() );\n} else {\n    $text = $response->get_text();\n}<\/code><\/pre>\n
Quello che rende questa API davvero potente \u00e8 che \u00e8 completamente agnostica rispetto al provider<\/strong>. Potete chiamare OpenAI, Anthropic (Claude) o Google Gemini con lo stesso codice \u2014 la scelta del provider \u00e8 gestita dall’utente nella nuova schermata Connectors<\/em> dell’admin.<\/p>\n
Attenzione: il pacchetto standalone \u00e8 deprecato<\/h3>\n
Se stavate usando il pacchetto wp-ai-client<\/code> come plugin separato durante lo sviluppo, sappiate che su WordPress 7.0+ l’infrastruttura PHP del SDK esterno viene disabilitata automaticamente \u2014 il core lo gestisce nativamente. I REST API endpoints<\/em> e la JavaScript API<\/em> del pacchetto restano attivi perch\u00e9 non sono ancora nel core, ma la migrazione \u00e8 inevitabile.<\/p>\n
Nel mio plugin AI Publisher WP<\/em>, ho gi\u00e0 iniziato a predisporre un layer di compatibilit\u00e0 che rileva la versione di WordPress e usa l’API nativa quando disponibile. Ve lo consiglio caldamente.<\/p>\n
La Connectors API: Gestione Centralizzata dei Servizi Esterni<\/h2>\n
WordPress 7.0 introduce la Connectors API<\/strong>, un framework per registrare e gestire connessioni a servizi esterni con focus iniziale sui provider AI. Questo significa gestione centralizzata delle API key<\/em>, provider discovery<\/em> e una UI admin dedicata sotto Impostazioni \u2192 Connectors<\/strong>.<\/p>\n
L’hook principale per registrare nuovi tipi di connector \u00e8 wp_connectors_init<\/code>:<\/p>\n
add_action( 'wp_connectors_init', function( $registry ) {\n    \/\/ I provider AI registrati con WP AI Client\n    \/\/ ottengono il connector automaticamente.\n    \/\/ Per servizi custom:\n    $registry->register( 'my-custom-service', array(\n        'label'       => 'My Custom API',\n        'description' => 'Connessione al servizio XYZ',\n        'fields'      => array(\n            'api_key' => array(\n                'label' => 'API Key',\n                'type'  => 'secret',\n            ),\n        ),\n    ) );\n} );<\/code><\/pre>\n
Limitazione importante per la 7.0<\/strong>: nella release iniziale, la schermata Connectors supporta solo i 3 provider ufficiali (OpenAI, Anthropic, Google) con configurazione hardcoded. L’estensibilit\u00e0 completa per provider di terze parti \u00e8 pianificata per WordPress 7.1<\/strong>. Tuttavia, l’hook connections-wp-admin-init<\/code> e le API di registrazione sono gi\u00e0 disponibili per chi vuole prepararsi.<\/p>\n
Se state sviluppando un plugin AI, il mio consiglio \u00e8: registrate il vostro provider con il WP AI Client e il connector verr\u00e0 creato automaticamente con i metadati corretti. Non serve codice aggiuntivo.<\/p>\n
DataViews: il Breaking Change che Rompe i Plugin di Admin<\/h2>\n
Questo \u00e8 il cambiamento che mi ha dato pi\u00f9 grattacapi durante i test. Il componente DataViews<\/strong> \u2014 usato per le liste di post, pagine e altri contenuti nell’admin \u2014 ha subito una modifica strutturale alla configurazione del raggruppamento.<\/p>\n
Prima (WordPress 6.9)<\/h3>\n
const view = {\n    type: 'table',\n    groupByField: 'status'\n};<\/code><\/pre>\n
Dopo (WordPress 7.0)<\/h3>\n
const view = {\n    type: 'table',\n    groupBy: {\n        field: 'status',\n        direction: 'asc',\n        showLabel: true\n    }\n};<\/code><\/pre>\n
Il vecchio groupByField<\/code> (stringa) \u00e8 stato sostituito da un oggetto groupBy<\/code> che supporta field<\/em>, direction<\/em> e label visibility<\/em>. Qualsiasi plugin che personalizza le liste nell’admin usando DataViews deve aggiornare questa sintassi<\/strong>, altrimenti si rompe silenziosamente.<\/p>\n
Come ho scritto nella mia guida alla roadmap di WordPress 7.0<\/a>, la Phase 3 Collaboration porta con s\u00e9 molti cambiamenti strutturali, e DataViews \u00e8 uno dei pi\u00f9 impattanti.<\/p>\n
PHP-Only Blocks: Addio JavaScript Obbligatorio<\/h2>\n
Questa \u00e8 stata una delle novit\u00e0 pi\u00f9 apprezzate dalla community, e devo dire che nella mia esperienza semplifica enormemente lo sviluppo. WordPress 7.0 permette di registrare blocchi interamente in PHP<\/strong>, senza una singola riga di JavaScript:<\/p>\n
register_block_type( 'mio-plugin\/info-box', array(\n    'supports' => array(\n        'autoRegister' => true,\n    ),\n    'attributes' => array(\n        'title' => array(\n            'type'    => 'string',\n            'default' => 'Titolo',\n        ),\n        'showBorder' => array(\n            'type'    => 'boolean',\n            'default' => true,\n        ),\n        'columns' => array(\n            'type'    => 'integer',\n            'default' => 2,\n        ),\n    ),\n    'render_callback' => function( $attributes ) {\n        $border = $attributes['showBorder'] ? ' style=\"border:1px solid #ccc\"' : '';\n        return sprintf(\n            '<div class=\"info-box\"%s><h3>%s<\/h3><\/div>',\n            $border,\n            esc_html( $attributes['title'] )\n        );\n    },\n) );<\/code><\/pre>\n
Con 'autoRegister' => true<\/code>, il blocco appare nell’editor e WordPress genera automaticamente gli Inspector Controls<\/em> per i tipi di attributo supportati: string<\/strong>, integer<\/strong>, boolean<\/strong> e enum<\/strong>. Niente pi\u00f9 build chain React solo per un blocco semplice.<\/p>\n
Block Visibility e Responsive Styling Controls<\/h2>\n
WordPress 7.0 introduce i Block Visibility controls<\/strong> nativi: ogni blocco pu\u00f2 ora essere mostrato o nascosto in base alla dimensione dello schermo, direttamente dall’editor. Per gli sviluppatori di plugin che offrivano questa funzionalit\u00e0 tramite plugin dedicati (e ce ne sono decine), questo significa potenziale conflitto.<\/p>\n
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\u00e0, rischiate comportamenti imprevedibili. Nella mia esperienza, la soluzione migliore \u00e8 rendere il vostro plugin consapevole della versione di WordPress e disabilitare i controlli duplicati quando il core li fornisce nativamente.<\/p>\n
Requisiti PHP Aggiornati e Compatibilit\u00e0<\/h2>\n
WordPress 7.0 alza il requisito minimo di PHP a 7.4<\/strong>, abbandonando ufficialmente il supporto per PHP 7.2 e 7.3. Se gestite server come faccio io con Plesk Obsidian<\/a>, questo non dovrebbe essere un problema \u2014 PHP 8.3 \u00e8 lo standard ormai. Ma se avete clienti su hosting condivisi datati, \u00e8 il momento di forzare l’aggiornamento.<\/p>\n
Per verificare la compatibilit\u00e0 del vostro plugin con PHP 7.4+, usate PHPCompatibility<\/em> con phpcs:<\/p>\n
# Installare PHPCompatibility\ncomposer require --dev phpcompatibility\/php-compatibility\n\n# Verificare compatibilit\u00e0\nphpcs --standard=PHPCompatibility --runtime-set testVersion 7.4- mio-plugin\/<\/code><\/pre>\n
Migration Path Completo: la Mia Checklist Operativa<\/h2>\n
Dopo aver migrato tre plugin ai cambiamenti di WordPress 7.0, ho consolidato questa checklist che uso su ogni progetto:<\/p>\n
    \n
  1. Ambiente di test<\/strong>: create un ambiente staging con WordPress 7.0 Beta 5 o RC1. Usate WordPress Beta Tester<\/a> o WP-CLI: wp core update --version=7.0-RC1<\/code><\/li>\n
  2. Audit PHP<\/strong>: eseguite phpcs con PHPCompatibility per identificare codice incompatibile con PHP 7.4+<\/li>\n
  3. DataViews<\/strong>: cercate nel vostro codice ogni occorrenza di groupByField<\/code> e sostituitela con il nuovo oggetto groupBy<\/code><\/li>\n
  4. Editor iframe<\/strong>: verificate che i vostri blocchi non facciano riferimento al document<\/code> globale in JavaScript \u2014 l’editor iframed (puntato a 7.1 ma gi\u00e0 attivo nel plugin Gutenberg) isola gli stili<\/li>\n
  5. WP AI Client<\/strong>: se usate il pacchetto standalone, pianificate la migrazione all’API nativa del core<\/li>\n
  6. Connectors API<\/strong>: se il vostro plugin gestisce connessioni a servizi esterni, valutate l’integrazione con la nuova API<\/li>\n
  7. PHP-only blocks<\/strong>: considerate la migrazione dei blocchi semplici a autoRegister<\/code> per eliminare dipendenze JavaScript<\/li>\n
  8. Block Visibility<\/strong>: verificate conflitti con i nuovi controlli responsive nativi<\/li>\n
  9. Test automatizzati<\/strong>: eseguite la vostra test suite su WordPress 7.0 \u2014 i test PHPUnit con WP_UnitTestCase funzionano senza modifiche<\/li>\n
  10. Field Guide<\/strong>: consultate la Field Guide ufficiale<\/a> pubblicata con la RC1 per la lista completa delle funzioni deprecate<\/li>\n<\/ol>\n
    Impatto sull’Ecosistema Plugin: Cosa Aspettarsi<\/h2>\n
    Dalla mia analisi delle beta, i plugin pi\u00f9 a rischio di incompatibilit\u00e0 sono:<\/p>\n