WordPress 7.1: checklist tecnica per preparare temi e plugin all’aggiornamento

WordPress 7.1 introduce cambiamenti che possono incidere sulla compatibilità di temi, plugin e flussi editoriali. Le aree da controllare con maggiore attenzione comprendono l’editor dei post sempre in iframe, l’elaborazione delle immagini nel browser, gli stili responsive di theme.json, la Libreria media, jQuery UI e la nuova API pubblica per le icone SVG.

Questo dossier è aggiornato al 12 agosto 2026, quando WordPress 7.1 risultava in fase RC3, con rilascio programmato per il 19 agosto 2026. Una Release Candidate deve essere utilizzata esclusivamente in un ambiente di test: non va installata su un sito in produzione.

La release comprende oltre 310 ticket Core, più di 180 correzioni Core, quasi 600 miglioramenti Gutenberg e oltre 630 bug fix Gutenberg. Questi numeri descrivono la portata dell’aggiornamento, ma non dimostrano che ogni sito diventerà automaticamente più veloce. Qualsiasi valutazione relativa alla WordPress performance deve essere basata su benchmark eseguiti con il tema, i plugin e la configurazione effettivamente utilizzati.

WordPress 7.1: cosa sapere prima di iniziare i test

Le novità documentate non devono essere confuse con benefici prestazionali garantiti. Alcuni cambiamenti possono ridistribuire il lavoro tra server e browser o consentire di razionalizzare CSS e dipendenze, ma il risultato dipende dall’implementazione del singolo sito.

La verifica pre-aggiornamento può essere organizzata in sei aree:

1. post editor sempre eseguito in iframe;
2. elaborazione client-side delle immagini;
3. stili responsive e pseudo-stati in theme.json;
4. infinite scroll nella Libreria media e nel Media Modal;
5. aggiornamento a jQuery UI 1.14.2;
6. adozione della SVG Icon API pubblica.

L’ordine dei controlli va adattato al progetto. Un sito con numerosi blocchi personalizzati potrebbe concentrare i rischi nell’editor, mentre un portale con molti upload e dimensioni immagine custom richiederà test più approfonditi sulla nuova pipeline media.

Preparare staging, benchmark e rollback

Prima di aggiornare temi e plugin, serve uno staging sufficientemente simile alla produzione. Il confronto è significativo soltanto se database, file media, configurazione server, cache e CDN sono comparabili.

Configurazione dell’ambiente di prova

• Creare una copia realistica del sito, eliminando o proteggendo gli eventuali dati sensibili.
• Preparare un backup e una procedura di rollback prima di installare la Release Candidate.
• Installare la RC più recente esclusivamente in staging.
• Attivare WP_DEBUG, WP_DEBUG_LOG e gli strumenti di debugging JavaScript.
• Verificare la console del browser e i log PHP durante ogni flusso di test.
• Ripetere le prove con i ruoli Amministratore, Editor e Autore.

Creare una baseline attendibile

Le misurazioni vanno raccolte prima su WordPress 7.0.x e poi ripetute, nelle stesse condizioni, dopo l’aggiornamento. Tra gli indicatori da confrontare rientrano:

• TTFB e tempo di esecuzione PHP;
• numero e durata delle query SQL;
• cache hit rate;
• CPU e memoria del server durante gli upload;
• numero di richieste generate dai flussi media;
• reattività dell’editor e memoria utilizzata dal browser;
• Core Web Vitals delle pagine rappresentative.

Per ottenere dati utili, occorre usare gli stessi contenuti, dispositivi, profili di cache e operazioni. Una singola misurazione isolata non consente di attribuire una differenza alla nuova versione.

Priorità alta: testare il post editor sempre in iframe

In WordPress 7.1 il post editor viene sempre eseguito in un iframe, anche quando sono presenti metabox legacy. È una delle aree più esposte a possibili incompatibilità, soprattutto per estensioni sviluppate assumendo che editor e interfaccia amministrativa condividano lo stesso documento.

L’audit deve individuare plugin o script che:

• accedono direttamente al DOM dell’editor;
• usano window.document senza considerare il documento dell’iframe;
• caricano il CSS soltanto nel documento padre;
• posizionano popup, tooltip o overlay rispetto al viewport principale;
• gestiscono eventi drag-and-drop tra aree appartenenti a documenti diversi.

Flussi da provare nell’editor

• Inserimento, modifica, duplicazione e rimozione dei blocchi personalizzati.
• Metabox legacy e relativi campi.
• Toolbar, controlli laterali, modali e selettori di media.
• Drag-and-drop di blocchi, file e componenti personalizzati.
• Popup, tooltip e overlay, verificandone posizione e interazione.
• Template, pattern e variazioni di stile.
• Caricamento dei font e corrispondenza tra CSS dell’editor e frontend.

Errori nella console, stili mancanti o comportamenti anomali devono essere documentati, ma non vanno presentati come regressioni generali di WordPress 7.1 finché non sono stati riprodotti e attribuiti con precisione.

Immagini nel browser: cosa cambia e cosa misurare

WordPress 7.1 trasferisce parte dell’elaborazione delle immagini e delle thumbnail al browser tramite wasm-vips. Il server continua comunque a controllare MIME type, dimensioni, permessi e metadati. Quando l’elaborazione client-side non è supportata, è previsto un fallback sul server.

Questo cambiamento non equivale all’eliminazione del lavoro server-side. Può ridurre alcuni picchi di CPU e memoria sul server, ma potrebbe anche aumentare le richieste o le risorse utilizzate dal dispositivo dell’utente. Entrambe sono ipotesi da verificare sul progetto concreto.

Checklist per gli upload

• Provare immagini che attivano tutte le dimensioni personalizzate registrate da tema e plugin.
• Verificare plugin di compressione, conversione WebP o AVIF e applicazione di watermark.
• Testare HEIC, AVIF, UltraHDR JPEG e GIF animate nei flussi in cui sono normalmente utilizzati.
• Controllare il codice collegato a wp_generate_attachment_metadata.
• Simulare il fallback server-side tramite il filtro wp_client_side_media_processing_enabled.
• Esaminare gli effetti di eventuali header di cross-origin isolation su font, iframe, script, embed e servizi esterni.

Metriche da confrontare

Durante le prove è utile registrare la durata completa dell’upload, il numero di richieste, CPU e memoria sul server e il consumo di risorse nel browser. I test devono includere sia dispositivi adeguati sia dispositivi meno potenti, se rappresentativi del pubblico editoriale.

Solo questi confronti permettono di capire se la nuova distribuzione del lavoro produce un vantaggio reale di WordPress performance oppure introduce un costo in un altro punto del processo.

Responsive styles in theme.json: controlli per temi e blocchi

WordPress 7.1 consente di definire stili per viewport mobile e tablet attraverso le chiavi @mobile e @tablet in theme.json. Non esiste una chiave @desktop: lo stile predefinito del blocco rappresenta il desktop e continua ad applicarsi alle proprietà che non vengono sovrascritte.

I breakpoint predefiniti indicati dalla documentazione sono 480px per mobile e 782px per tablet. Possono essere configurati tramite l’impostazione di primo livello settings.viewport, rispettando i formati previsti dalla documentazione definitiva.

Verifiche sul CSS

• Confrontare la resa nell’editor e nel frontend.
• Cercare duplicazioni tra gli stili nativi e le media query già presenti.
• Controllare specificità, ordine delle regole e proprietà ereditate.
• Provare i blocchi che usano i supporti standard e quelli dotati di controlli personalizzati.
• Verificare template, pattern e variazioni di stile alle diverse larghezze.

L’interfaccia di editing responsive può essere disattivata, ma questa operazione non impedisce la generazione e la visualizzazione degli stili responsive già salvati.

La release introduce inoltre il supporto agli pseudo-stati come :hover, :focus, :focus-visible e :active. Nella documentazione fornita il supporto è limitato ai blocchi Button e Navigation Link.

Gli stili nativi possono offrire l’opportunità di ridurre parte del CSS proprietario. Il risultato non è automatico: prima di rimuovere regole esistenti bisogna verificare copertura, compatibilità e resa visiva.

Libreria media: verificare l’infinite scroll nei flussi reali

La griglia della Libreria media e il Media Modal adottano l’infinite scroll come impostazione predefinita. Il comportamento può essere modificato dal singolo utente.

La verifica non dovrebbe limitarsi all’apertura della griglia. Occorre provare i flussi editoriali completi e le eventuali personalizzazioni:

• sistemi DAM integrati con WordPress;
• tassonomie applicate agli allegati;
• filtri e bulk action;
• selettori di media personalizzati;
• librerie contenenti molti file;
• ricerca e selezione eseguite dai diversi ruoli.

L’effetto dell’infinite scroll su prestazioni, usabilità e accessibilità non è univoco. È quindi opportuno verificare anche l’interazione con tecnologie assistive e dispositivi poco potenti, senza presumere che si presenteranno necessariamente problemi.

jQuery UI 1.14.2: audit delle dipendenze JavaScript

WordPress 7.1 aggiorna jQuery UI dalla versione 1.13.3 alla 1.14.2. Il dossier segnala la rimozione delle seguenti API:

• $.fn._form
• $.ui.ie
• $.ui.safeActiveElement
• $.ui.safeBlur

Questi riferimenti vanno cercati nel codice di temi, plugin e personalizzazioni. L’assenza delle quattro API non esclude altri problemi: è necessario provare datepicker, sortable, draggable, dialog e autocomplete, comprese le personalizzazioni CSS applicate al markup prodotto dai componenti.

L’aggiornamento riporta inoltre la fine del supporto a Internet Explorer ed Edge Legacy. Prima della pubblicazione è comunque opportuno confermare nella documentazione definitiva la versione distribuita e le API effettivamente rimosse.

SVG Icon API: opportunità e controlli

Con WordPress 7.1 la SVG Icon API diventa pubblica e consente di registrare e renderizzare icone e raccolte personalizzate. Per temi e plugin può essere un’occasione per uniformare la gestione delle icone, ma l’adozione richiede un audit.

• Verificare namespace e possibili collisioni tra raccolte.
• Controllare sanitizzazione e contenuto dei file SVG.
• Validare viewBox, dimensioni e comportamento responsive.
• Controllare l’accessibilità delle icone nei diversi contesti.
• Individuare icon font e vecchie librerie ancora caricati.

La nuova API può ridurre dipendenze duplicate soltanto se i caricamenti precedenti vengono effettivamente rimossi. Usare la nuova API lasciando attive tutte le librerie esistenti non garantisce una riduzione del payload.

React 19 è rinviato

React 19 non è incluso in WordPress 7.1. La release resta su React 18.3, quindi questo aggiornamento non richiede una migrazione obbligatoria a React 19.

Eventuali test anticipati con React 19 sono facoltativi e possono servire a preparare versioni future di temi o plugin. Non devono però essere inseriti tra i requisiti necessari per approvare l’aggiornamento a WordPress 7.1.

Checklist per il via libera alla produzione

L’aggiornamento può essere pianificato soltanto dopo aver verificato almeno questi punti:

• i flussi editoriali funzionano con Amministratore, Editor e Autore;
• blocchi personalizzati, metabox, modali e controlli dell’editor sono operativi;
• console e log non contengono errori rilevanti non risolti;
• upload, formati immagine, dimensioni custom e fallback sono stati provati;
• editor e frontend mostrano CSS coerente alle diverse larghezze;
• Libreria media, Media Modal e integrazioni esterne funzionano;
• le dipendenze da jQuery UI sono state controllate;
• i benchmark prima e dopo l’aggiornamento sono stati confrontati;
• incompatibilità, correzioni e differenze prestazionali sono documentate;
• backup e procedura di rollback sono stati verificati.

La decisione deve distinguere sempre le funzionalità documentate dai benefici ipotizzati. Un miglioramento misurato su un sito non può essere esteso automaticamente a installazioni con configurazioni differenti.

Domande frequenti su WordPress 7.1

Quando è previsto il rilascio di WordPress 7.1?

Il dossier aggiornato al 12 agosto 2026 indica il rilascio programmato per il 19 agosto 2026. Prima della pubblicazione o dell’aggiornamento in produzione bisogna verificare sulla fonte ufficiale se la versione stabile è stata effettivamente distribuita.

È sicuro installare WordPress 7.1 RC3 su un sito in produzione?

No. La Release Candidate deve essere usata esclusivamente in staging o in altri ambienti di test. Per la produzione bisogna attendere la versione stabile e mantenere disponibili backup e rollback.

WordPress 7.1 migliora automaticamente le performance del sito?

No. La release introduce cambiamenti che possono incidere sulla distribuzione delle risorse, ma il risultato dipende da tema, plugin, server, cache, CDN e utilizzo del sito. Le differenze devono essere misurate con benchmark prima e dopo l’aggiornamento.

Quali plugin rischiano maggiormente incompatibilità con l’editor sempre in iframe?

Richiedono particolare attenzione le estensioni che accedono direttamente al DOM, usano window.document, caricano CSS nel documento padre o gestiscono popup, tooltip, overlay e drag-and-drop rispetto al viewport principale. Si tratta di fattori di rischio da verificare, non di incompatibilità certe.

Come testare l’elaborazione client-side delle immagini e il fallback server-side?

Occorre provare gli upload con le dimensioni immagine personalizzate, i formati utilizzati dal sito e gli eventuali plugin di compressione, conversione o watermark. Il fallback può essere simulato tramite il filtro wp_client_side_media_processing_enabled, confrontando richieste, tempi, CPU e memoria.

Cosa bisogna controllare negli stili @mobile e @tablet di theme.json?

Bisogna verificare la resa tra editor e frontend, i conflitti con le media query esistenti, la specificità delle regole e le proprietà non sovrascritte che continuano a ereditare lo stile predefinito del blocco.

Quali API vengono rimosse con jQuery UI 1.14.2?

Il dossier indica $.fn._form, $.ui.ie, $.ui.safeActiveElement e $.ui.safeBlur. La rimozione deve essere confermata sulla documentazione definitiva della versione distribuita con WordPress 7.1.

L’infinite scroll della Libreria media può essere modificato dall’utente?

Sì. È il comportamento predefinito nella griglia della Libreria media e nel Media Modal, ma può essere modificato dal singolo utente.

WordPress 7.1 include React 19?

No. WordPress 7.1 resta su React 18.3. Non è richiesta una migrazione obbligatoria a React 19 per questo aggiornamento.

Quali benchmark confrontare prima e dopo l’aggiornamento?

Tra le misure utili rientrano TTFB, tempo PHP, query SQL, cache hit rate, CPU e memoria durante gli upload, richieste media, reattività dell’editor, memoria del browser e Core Web Vitals.

Supporto per audit e aggiornamento

Se devi verificare un tema o un plugin, posso supportarti nella preparazione dello staging, nell’audit di compatibilità, nei benchmark e nella definizione di un piano di aggiornamento con rollback. Contattami per saperne di più.

Fonte

Approfondimento di riferimento: What’s new for developers? (August 2026), WordPress Developer Blog.

Fonti

1. What’s new for developers? (August 2026) (developer.wordpress.org)
2. WordPress 7.1 – Make WordPress Core (make.wordpress.org)