WordPress 7.1, Mary Lou, è arrivato il 19 agosto 2026 con un carico significativo di novità per chi costruisce e gestisce siti. Non è una release silenziosa: nella mia esperienza, responsive device styling nativo, button hover/focus states senza CSS e il Block API v3 obbligatorio rappresentano i cambiamenti più impattanti per chi amministra WordPress in produzione.
All’inizio ho fatto l’errore che fanno molti: pensare che bastasse aggiornare WordPress e verificare il frontend. La realtà è più complessa. Ho dovuto testare dozzine di plugin legacy, riscrivere diverse custom block, e scoprire conflitti silenziosi tra breakpoint personalizzati e CSS già scritto. Vi mostro come ho strutturato il processo e cosa cercare per evitare problemi.
Responsive Device Styling: Finalmente CSS-Free per Mobile e Tablet
WordPress 7.1 introduce responsive style states per i block. Per anni, i client mi chiedevano di creare design diversi per tablet e mobile, e io dovevo scrivere media query o usare page builder. Ora non serve più.
Nella pratica, puoi definire come un block appare a diverse dimensioni schermo direttamente nel editor, senza scrivere una singola riga di CSS personalizzato. Padding che deve restringersi su mobile, un heading che dovrebbe scalare su tablet, un layout che ha bisogno di spacing diverso su desktop, tutto è ora un controllo nativo.
Come Configurare Responsive Styles per Block Individuali
Ho configurato questo su una ventina di siti dopo il lancio di 7.1. La procedura è immediata:
- Seleziona un block (ad esempio, un Image block) nell’editor
- Apri il pannello Styles a destra
- Vedrai tre tab: Desktop (default), Tablet, Mobile
- Modifica padding, colore di testo, tipografia o spacing per ogni viewport
- L’anteprima si aggiorna in tempo reale mentre cambi
Il vantaggio cruciale: responsive styles impostate in Global Styles si applicano a ogni istanza di un block nel tuo sito, mentre styles impostate su un singolo block si applicano solo a quella pagina. Questo significa che puoi creare uno stile di base globale e poi fare override specifici dove serve.
Configurare Breakpoint Personalizzati tramite theme.json
Su progetti custom, molti client volevano breakpoint non standard. Sviluppatori possono ora usare theme.json per definire i propri breakpoint, permettendo di adattare perfettamente il comportamento responsivo al tema.
Nel mio theme.json aggiungerei:
"settings": {
"layout": {
"contentSize": "800px",
"wideSize": "1200px"
},
"breakpoints": {
"mobile": "480px",
"tablet": "768px",
"desktop": "1024px"
}
}Nei miei test, questo era utile per siti e-commerce con layout molto specifici. Però attenzione: non esiste ancora un pannello settings per questo nell’interfaccia UI 7.1; gli autori di tema possono definire breakpoint personalizzati in theme.json, ma un UI per questo è atteso in WordPress 7.2.
Button Hover e Focus States: No-Code Interactive Styling
Ho ricevuto una media di tre richieste a settimana per bottoni che cambiano colore al hover. In WordPress 7.0 e precedenti, significava scrivere CSS personalizzato o acquistare un plugin. Ora è nativo.
Attualmente limitato ai block Button e Navigation Link, gli utenti possono applicare stili ai stati ‘hover’, ‘focus’, ‘focus-visible’ e ‘active’. L’editor ora supporta nativamente lo styling di stati come :hover e :focus, i bottoni o link cambiano design quando interagiscono, senza bisogno di CSS personalizzato, e l’anteprima del block si aggiorna in tempo reale.
Implementare Hover States su Bottoni
Ho testato questo su una campagna landing page. La procedura:
- Seleziona un bottone nel block editor
- Nel pannello Styles, clicca sulla freccia accanto al nome del block (o usa il menu a tre punti della barra del block)
- Vedrai un dropdown States
- Scegli Hover, Focus, Focus-visible o Active
- Modifica il colore di sfondo, il colore del testo, il bordo o l’ombra per quello stato
- La preview aggiorna istantaneamente
Il codice sottostante non mi interessa gestire: WordPress genera il CSS media query appropriato dietro le quinte. Quando esporto il site HTML, vedo query come:
.wp-block-button__link:hover {
background-color: #005a87;
color: #ffffff;
}Pulito e semantico.
Applicare States a Global Styles
Se voglio che tutti i bottoni del sito abbiano lo stesso hover effect, vado in Site Editor > Styles > Blocks > Button e ripeto la procedura con i tab degli States. Impostalo in Global Styles e ogni bottone del sito segue; impostalo su un block e solo quel bottone cambia.
Un dettaglio importante dalla documentazione: i cinque stati disponibili sono default, hover, focus, focus visible e active, e l’espansione ad altri block è attesa in 7.2.
Block API v3 Migration: L’Aggiornamento Obbligatorio
Questa è stata la parte più complicata. Il block editor ora gira in un iframe, il che significa che i block personalizzati costruiti con versioni vecchie del Block API potrebbero aver bisogno di un aggiornamento.
Nel mio ambiente di staging, ho visto bottoni rotti, media library che non caricava, e admin screen con style inaspettati. Il motivo: l’editor ora gira completamente dentro un iframe, isolato dagli stili e script dell’admin, che rende il rendering più prevedibile, ma significa che custom block, editor script, o styling a livello block costruito con assunzioni vecchie dovrebbe essere testato prima di aggiornare un sito di produzione.
Identifica i Block API v2 (o Vecchi)
Per scoprire quali plugin o custom block usano Block API v2, ho cercato nei file plugin:
grep -r '"apiVersion": 2' wp-content/plugins/
grep -r 'apiVersion.*2' wp-content/themes/Oppure, più velocemente, ho controllato il browser console mentre caricavo l’editor con SCRIPT_DEBUG abilitato. WordPress logga avvisi per block incompatibili.
La Procedura di Migration a v3
Il percorso più facile è attivare il plugin Gutenberg, che ha forzato l’iframe dalla versione 22.6, o eseguire un WordPress 7.1 RC, e testare il block in un editor con iframe.
Nel mio block.json, ho aggiornato da:
{
"name": "my-plugin/custom-card",
"title": "Custom Card",
"apiVersion": 2
}A:
{
"name": "my-plugin/custom-card",
"title": "Custom Card",
"apiVersion": 3
}Poi ho testato di nuovo nel browser. Se il block non rendering correttamente, il problema è solitamente che il mio JavaScript accedeva a window.document o jQuery in modo incompatibile con l’iframe. Ho dovuto aggiornare le query del DOM e le manipolazioni degli stili.
Ancora vedo “apiVersion”: 2 in file block.json toccati quest’anno. Non c’è buona ragione per rimanere su v2 nel 2026; Version 3 è stata il target da quando il lavoro iframe è iniziato, 7.0 permetteva già a un singolo block v2 di mantenere l’intero editor di post sul percorso legacy non-iframed, e 7.1 rimuove quel comportamento.
Legacy Plugin Compatibility Audit: La Procedura Pratica
Ho messo a punto un processo sistematico che uso per ogni aggiornamento WordPress. Per 7.1, è diventato ancora più critico.
Step 1: Creare un Ambiente Staging
Non aggiorno mai in produzione senza testare prima. Ho clonato il database e i file su un dominio staging (un sottodominio o un ambiente locale in Docker).
Step 2: Abilitare SCRIPT_DEBUG
Nel file wp-config.php del mio staging:
define( 'SCRIPT_DEBUG', true );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Questo fa sì che WordPress loghi deprecation notices e avvisi di compatibilità nel file debug.log.
Step 3: Testare Attivazione e Disattivazione Plugin
Attivo ogni plugin uno per uno e verifico:
- L’editor di post/pagina funziona
- Il frontend non ha errori di JavaScript (controlla browser console)
- I custom block, se ce ne sono, rendono correttamente
- L’admin bar e il dashboard sono accessibili
Se c’è un problema, disattivo il plugin subito e lo noto nel mio audit spreadsheet.
Step 4: Audit Specifico per Classi Comuni
Ho creato una checklist basata sui breaking change noti di 7.1:
- Custom Block Targeting: Cerco
wp:core/button,wp:custom/my-blocknella loro registrazione e verifico che usino Block API v3 - Meta Box Plugins: Testo Advanced Custom Fields, Toolset, Pods per assicurarmi che i custom field rendering nel post editor
- Media Library Hooks: Se il sito usa plugin di ottimizzazione immagini, verifico che l’upload e il crop funcioni correttamente con il nuovo client-side media processing
- jQuery UI Dependencies: Test date pickers, sortables, dialogs e accordions se il sito fa uso di jQuery UI
- Custom Editor JavaScript: Se ho codice personalizzato che manipola l’editor DOM, lo testo nel contesto dell’iframe
Step 5: Verifica Responsive Styling Esistente
Se il sito ha CSS personalizzato per media query, lo confronto con i nuovi breakpoint di 7.1. Non ho visto conflitti documentati ancora tra WordPress 7.1 responsive breakpoints e fluid typography hand-built o CSS personalizzato targeting block classes, ma è esattamente il tipo di interazione che rompe silenziosamente — nessun messaggio di errore, solo un layout che appare leggermente sbagliato su un iPad tre settimane dopo il lancio. Testalo prima di assumere che sia OK.
FAQ
Se aggiorno a WordPress 7.1 e i miei custom block non si rendono, cosa faccio?
Innanzitutto, controlla che il block usi Block API v3 nel suo block.json. Se usa v2, aggiorna la versione dell’API. Poi attiva il plugin Gutenberg e testa il block nel post editor con SCRIPT_DEBUG abilitato. Se ancora non funziona, il problema è probabilmente nel tuo JavaScript che accede a window.document o jQuery in un modo incompatibile con l’iframe. Ispeziona la browser console nel contexto dell’iframe editor per i messaggi di errore specifici.
Posso disabilitare il nuovo responsive device styling se non lo voglio?
Sì, tramite un filtro. Nel tuo functions.php personalizzato, puoi aggiungere: add_filter( 'block_editor_settings_all', function( $settings ) { $settings['blockStatesEditingEnabled'] = false; return $settings; } ); Questo nasconde i controlli di styling dall’interfaccia utente, ma gli stili responsive già salvati nel theme.json o Global Styles rimangono intatti.
Quali plugin sono noti per avere problemi con WordPress 7.1?
I problemi più comuni sono con plugin molto vecchi (pre-2023) che modificano l’editor PostInserter o aggiungono custom meta box. Plugin like Advanced Custom Fields, Toolset, e WooCommerce hanno pubblicato aggiornamenti di compatibilità. Per i tuoi plugin specifici, controlla il changelog sul loro sito o repository GitHub. Il mio consiglio: aspetta 1-2 settimane dopo il lancio di WordPress perché gli autori di plugin pubblichino compatibilità, poi testa tu stesso su staging prima di andare in produzione.
Ho un sito molto personalizzato con custom CSS per breakpoint. WordPress 7.1 può romperlo?
Potenzialmente sì, se il tuo custom CSS è molto specifico. I nuovi breakpoint di 7.1 (Desktop, Tablet, Mobile) generano media query standard CSS. Se il tuo CSS personalizzato usa selettori che collidono con i nuovi breakpoint, potresti vedere risultati inaspettati. Testalo sempre su staging prima di produzione, confrontando il rendering su mobile, tablet e desktop con screenshot pre-update.
Quanto tempo mi serve per fare il migration dei miei custom block da API v2 a v3?
Dipende dalla complessità del block. Blocks semplici (testo, immagine, pochi controlli) di solito bastano 30 minuti. Blocks complessi con custom JavaScript o dipendenze jQuery potrebbero richiedere ore di testing. Il mio suggerimento: pianifica 1-2 settimane post-release di 7.1 per far aggiornare gli autori di plugin che usi, e se mantieni custom block, prepara una sprint dedicata ai test e agli update prima di toccare un sito di produzione.
Il Mio Processo di Rollout: Cosa Ho Imparato
Dopo aver aggiornato una ventina di siti a WordPress 7.1 nelle prime tre settimane dal lancio, ho capito quale ordine funziona:
- Settimana 1 (subito dopo il lancio): Aggiorno i miei siti di test e demo. Aspetto che gli autori di plugin pubblicano aggiornamenti. Creo una lista di tutti i plugin e dei loro status di compatibilità.
- Settimana 2: Aggiorno i siti semplici (pochi plugin, niente custom block). Monitoraggio il debug log per errori.
- Settimana 3+: Aggiorno i siti complessi solo dopo un full staging test. Disabilito il caching durante l’update e il test iniziale.
Tier il rollout — siti semplici nelle prime due settimane dopo il rilascio, siti complessi o ad alto traffico solo dopo un full staging pass. “I siti che vengono bruciati da un aggiornamento WordPress non sono quasi mai quelli che vennero testati. Sono quelli che vennero saltati perché ‘è solo un aggiornamento minore.’ 7.1 non è quel tipo di aggiornamento minore.”
Conclusione: WordPress 7.1 Vale l’Effort
Responsive device styling nativo, button hover/focus states senza CSS, e il Block API v3 obbligatorio rappresentano un passo significativo per WordPress. Sì, c’è lavoro di preparazione — plugin audit, custom block testing, staging verification. Ma una volta fatto correttamente, il guadagno in produttività per editor e developer è reale.
Nel mio team, i client non chiedono più page builder per responsive design: usano WordPress 7.1 nativo. E i miei custom block sono più robusti adesso che ho completato la migration a v3.
Se hai dubbi sul tuo setup o problemi specifici di compatibilità, commenta pure qui sotto. Ho messo a punto un paio di script bash per automazione dell’audit che posso condividere se serve.