WordPress 7.1 e Gutenberg: novità tecniche e checklist per le agenzie

WordPress 7.1 “Mary Lou”, pubblicato il 19 agosto 2026, introduce cambiamenti che richiedono attenzione soprattutto nei progetti con temi, blocchi e plugin personalizzati. Per agenzie e freelance, il punto non è soltanto conoscere le nuove funzioni: occorre verificare come l’isolamento dell’editor, le capacità di theme.json e le nuove API incidano sulle implementazioni esistenti.

È inoltre fondamentale distinguere il Core dalle evoluzioni successive del plugin Gutenberg. Le novità di Gutenberg 23.8 e 23.9 non sono automaticamente disponibili su un sito che utilizza soltanto WordPress 7.1.

WordPress 7.1: cosa cambia per agenzie e sviluppatori

La release può essere letta come un’evoluzione dello sviluppo WordPress verso quattro direzioni: maggiore isolamento dell’editor, design system dichiarativi, API pubbliche e interfacce amministrative componibili.

Tra gli aspetti più rilevanti da valutare rientrano:

• l’esecuzione dell’editor dei post in un iframe per tutti i temi;
• le nuove capacità responsive e gli stati interattivi di theme.json;
• la SVG Icon API per registrare e mostrare icone;
• l’ampliamento delle API collegate a DataViews, DataForm e alle interfacce per pagine, template, parti e pattern;
• l’evoluzione dell’Abilities API per automazioni e integrazioni;
• la possibilità di elaborare immagini nel browser tramite WebAssembly e libvips.

Questi elementi non hanno lo stesso impatto su ogni sito. Un progetto basato su componenti custom richiede controlli diversi rispetto a un’installazione priva di personalizzazioni. Per questo l’aggiornamento dovrebbe essere preceduto da un audit in staging.

Core 7.1 e Gutenberg 23.8–23.9: la distinzione necessaria

Gutenberg 23.8 e 23.9 sono release successive a WordPress 7.1. Sviluppano e perfezionano alcune delle fondamenta introdotte o ampliate dal Core, ma non devono essere trattate come parte automatica della release 7.1.

Installare Gutenberg in produzione soltanto per anticipare funzioni non stabilizzate può creare dipendenze premature. Le novità del plugin vanno quindi valutate in ambienti di test o in progetti pilota.

Editor sempre in iframe: i rischi per i progetti esistenti

In WordPress 7.1 l’editor dei post viene eseguito in un iframe per tutti i temi, anche quando sono presenti metabox legacy. Questo isolamento rende prioritario il controllo delle integrazioni che presuppongono un accesso diretto al documento padre.

Durante l’audit occorre verificare:

• blocchi custom e relative interazioni nell’editor;
• metabox legacy e componenti associati;
• script che accedono al documento padre;
• CSS caricato genericamente nell’area amministrativa ma non nel documento dell’editor;
• separazione fra asset destinati all’editor e asset dell’amministrazione;
• implementazioni precedenti alla Block API v3;
• componenti basati su jQuery UI, considerando l’aggiornamento alla versione 1.14.2 segnalato per WordPress 7.1.

Una regressione può manifestarsi come stile mancante, selettore non più applicato o comportamento JavaScript non coerente. La verifica deve quindi includere sia l’aspetto visivo sia le operazioni di inserimento, modifica e salvataggio dei contenuti.

theme.json: responsive design, viewport e stati interattivi

WordPress 7.1 amplia le possibilità di theme.json con stili responsive, viewport configurabili, text shadow e stati hover, focus, focus-visible e active.

Per le agenzie, queste capacità offrono l’opportunità di accentrare più regole nel design system dichiarativo. Ciò può ridurre la necessità di CSS ad hoc e favorire il riuso delle configurazioni, ma non rappresenta un risultato garantito: dipende dall’architettura del tema e dalla governance editoriale adottata.

Le attività consigliate sono:

1. aggiornare lo schema usato per la validazione di theme.json;
2. allineare gli strumenti dell’IDE;
3. validare i file esistenti;
4. testare breakpoint, viewport e stati interattivi;
5. decidere quali controlli rendere disponibili agli utenti del sito.

Gutenberg 23.8 corregge alcuni schemi di validazione collegati e permette di nascondere determinati controlli al cliente senza impedire il rendering degli stili già definiti. Anche in questo caso si tratta di un’evoluzione successiva, da non confondere con la dotazione standard del solo Core 7.1.

SVG Icon API: una gestione condivisa delle icone

La SVG Icon API introduce un modo pubblico e standardizzato per registrare e renderizzare le icone. Le funzioni indicate sono:

• wp_register_icon_collection() per registrare una collezione;
• wp_register_icon() per registrare un’icona;
• wp_get_icon() per recuperarla e renderizzarla.

Un’applicazione concreta consiste nell’organizzare le icone del brand come componente condiviso tra tema, blocchi e plugin. Per un’agenzia significa poter progettare una convenzione comune, evitando che ogni componente gestisca le proprie icone in modo isolato. La migrazione delle implementazioni esistenti deve comunque essere valutata caso per caso.

DataViews, DataForm e Site Editor estensibile

WordPress 7.1 amplia le API collegate a DataViews, DataForm e alle interfacce per pagine, template, parti e pattern. Sono basi utili per costruire esperienze amministrative più componibili.

Gutenberg 23.8 e 23.9 proseguono il lavoro attraverso la rimozione delle API private da DataViews e lo sviluppo del Site Editor estensibile. Quest’ultimo è però ancora sperimentale: non va presentato come un’API Core stabile o consolidata.

Per chi sviluppa plugin interni, la scelta prudente è provarlo in ambienti controllati o progetti pilota. Affidare subito funzionalità essenziali a interfacce ancora sperimentali potrebbe introdurre dipendenze premature.

Abilities API: infrastruttura per automazioni e integrazioni

L’Abilities API, introdotta in WordPress 6.9, viene ampliata in WordPress 7.1 con validazione, filtri, hook di esecuzione e schemi destinati a client esterni.

Questa infrastruttura può sostenere automazioni e integrazioni, ma non costituisce una soluzione di intelligenza artificiale completa o pronta all’uso. Non deve neppure essere descritta come intrinsecamente sicura: ruoli, autorizzazioni, validazione e comportamento delle integrazioni devono essere verificati nel contesto del singolo progetto.

Elaborazione dei media nel browser: cosa testare

WordPress 7.1 può elaborare le immagini nel browser tramite WebAssembly e libvips. I possibili benefici dipendono tuttavia da browser, dispositivo, formati e interazione con plugin di ottimizzazione o CDN.

Prima di approvare il flusso in produzione è opportuno controllare:

• i browser e i dispositivi rilevanti per il progetto;
• i formati di immagine utilizzati;
• la qualità dei risultati;
• la compatibilità con CDN e plugin di ottimizzazione;
• le operazioni abituali svolte nella Media Library.

La Media Library adotta inoltre lo scorrimento infinito come impostazione predefinita, con possibilità di opt-out individuale. Anche questo cambiamento deve essere incluso nei test dei flussi redazionali, soprattutto quando utenti con ruoli diversi lavorano sugli stessi contenuti.

Checklist di audit prima dell’aggiornamento

L’aggiornamento non dovrebbe partire direttamente dal sito in produzione. Una procedura di verifica può essere organizzata in questi passaggi:

1. Creare uno staging: clonare sito, configurazione e contenuti necessari ai test.
2. Aggiornare Core e dipendenze: verificare separatamente l’effetto delle componenti coinvolte.
3. Controllare l’iframe: provare blocchi custom, metabox, CSS e script che interagiscono con l’editor.
4. Verificare la Block API: individuare implementazioni precedenti alla versione 3.
5. Separare gli asset: controllare che fogli di stile e script siano caricati nel contesto corretto.
6. Validare theme.json: aggiornare schema e IDE, quindi provare viewport, stili responsive e stati interattivi.
7. Testare le dipendenze UI: verificare i componenti basati su jQuery UI.
8. Controllare i media: provare browser, dispositivi, formati, qualità, CDN e plugin di ottimizzazione.
9. Verificare accessibilità e ruoli: controllare interazioni, focus, permessi e flussi redazionali.
10. Provare le automazioni: validare input, hook, autorizzazioni e risultati delle integrazioni.

Gutenberg 23.8 e 23.9 possono essere esaminati separatamente in un ambiente di test. Non è consigliabile installarli in produzione soltanto per anticipare funzionalità sperimentali o non ancora consolidate nel Core.

Cosa non è incluso in WordPress 7.1

Per evitare aspettative errate, tre esclusioni devono essere esplicitate:

• la collaborazione in tempo reale non è abilitata nella release finale di WordPress 7.1;
• React 19 è stato rinviato e resta sperimentale nel plugin Gutenberg;
• la proposta di rimuovere il blocco Classic dall’inserter è stata annullata, quindi il blocco resta disponibile.

AI Modified con Conteniva

Serve un audit di compatibilità?

Per temi e plugin custom, la verifica deve tradurre le novità della release in test ripetibili e pertinenti al progetto. Posso supportare agenzie web, digital agency e freelance nell’audit tecnico di siti, blocchi, metabox e integrazioni prima dell’aggiornamento. Contattami per saperne di più.