Per agenzie, freelance e sviluppatori che mantengono siti personalizzati, prepararsi a WordPress 7.2 non significa cercare una singola incompatibilità valida per tutti. Significa individuare le aree dello stack potenzialmente interessate e organizzare test mirati su temi, plugin, blocchi, query e personalizzazioni dell’editor.
Questa è una checklist preliminare basata sulle informazioni disponibili al 15 ottobre 2026. WordPress 7.2 non è ancora stabile e alcuni elementi della roadmap potrebbero cambiare o non entrare nella versione finale.
Di cosa parlerò in questa pagina
WordPress 7.2: stato della release e date da ricordare
Il calendario indicato per il ciclo di rilascio prevede:
- Beta 1: 20 ottobre 2026;
- RC1 e Field Guide: 17 novembre 2026;
- release stabile: 8 dicembre 2026.
Le versioni preliminari permettono di verificare in anticipo lo stack tecnico, ma non devono essere utilizzate in produzione. I risultati ottenuti con la Beta andranno inoltre ricontrollati dopo RC1, quando Field Guide e Dev Notes consentiranno di distinguere meglio le modifiche effettivamente incluse da quelle rinviate.
Non emerge un problema di compatibilità universale. Il livello di attenzione dipende da quanto il progetto utilizza HTML sanificato, blocchi custom, componenti JavaScript, query personalizzate, estensioni della sidebar e CSS legato al markup generato da WordPress.
Cosa è confermato e cosa resta da verificare
Prima di stimare tempi e rischi conviene classificare le informazioni disponibili in quattro gruppi:
- Modifiche già implementate nei componenti citati: comprendono, per esempio, le API responsive pubbliche introdotte da Gutenberg 24.1.
- Deprecazioni: segnalano la necessità di intervenire, ma non equivalgono a una rimozione immediata.
- Elementi in roadmap: sono perseguiti durante il ciclo di sviluppo, senza garanzia che arrivino tutti nella release stabile.
- Aspetti da confermare: devono essere rivalutati dopo RC1 tramite Field Guide, Dev Notes e test aggiornati.
Il passaggio completo a React 19 è indicato come improbabile per WordPress 7.2. Anche Secrets API, sudo mode e le funzioni AI sviluppate attraverso plugin separati non vanno considerate caratteristiche Core definitive della release.
La collaborazione in tempo reale è invece intenzionalmente fuori dalla roadmap di WordPress 7.2.
Nuovo wp_kses(): quali flussi HTML controllare
Uno dei punti più delicati riguarda il rifacimento di wp_kses() sulla HTML API. L’obiettivo è WordPress 7.2 oppure 7.3, a seconda dell’esito dei test: la sua presenza nella 7.2 non è quindi ancora confermata.
Il nuovo comportamento può incidere sulla normalizzazione del markup restituito, sulla rimozione dei contenuti degli elementi script e style e sulla gestione di SVG, MathML, commenti e HTML malformato.
Dove cercare possibili dipendenze dall’output
- chiamate alle funzioni
wp_kses*; - confronti letterali sull’HTML sanificato;
- snapshot test che dipendono dall’esatta formattazione del markup;
- form builder e importer;
- shortcode e blocchi dinamici;
- flussi che accettano SVG personalizzati.
Il controllo non deve limitarsi a verificare se il contenuto viene salvato. Occorre confrontare anche il markup prima e dopo la sanificazione e osservare eventuali conseguenze sul rendering o sui test automatici.
È previsto il filtro wp_kses_force_legacy_parser per ripristinare il parser precedente. Va considerato esclusivamente una soluzione temporanea utile durante diagnosi e transizione, non una correzione definitiva.
API responsive e block supports: test per i blocchi custom
Gutenberg 24.1 rende pubblici gli strumenti che permettono ai blocchi di terze parti di costruire controlli responsive analoghi a quelli dei blocchi Core. Il pacchetto @wordpress/block-editor espone:
getStyleForState();setStyleForState().
Lo store del block editor introduce inoltre i selettori:
getSelectedBlockStyleState();hasSelectedBlockStyleState().
Per le librerie di blocchi personalizzati è opportuno verificare la struttura dell’attributo style, le migrazioni dei contenuti salvati e il comportamento dei controlli per breakpoint. I test devono includere sia l’editor sia il front-end.
L’estensione dei block supports a numerosi blocchi Core può produrre nuove classi HTML, per esempio has-link-color. Se il tema o un plugin utilizza selettori molto specifici, reset CSS o regole che presumono una struttura fissa, possono emergere regressioni visive.
Visual regression test consigliati
- template e archivi;
- pattern riutilizzati nel progetto;
- navigazioni;
- gallerie;
- blocchi custom e blocchi dinamici;
- stati responsive e varianti di stile.
Icone, componenti deprecati e pannelli dell’editor
Le icone Core stanno passando da forme basate su fill a icone basate su stroke. Le personalizzazioni CSS che forzano il riempimento potrebbero quindi non produrre più il risultato previsto. Quando un progetto dipende dai relativi pacchetti, è indicato aggiornare e verificare insieme @wordpress/icons e @wordpress/components.
Cinque componenti risultano deprecati dalla 7.2:
Divider;ResponsiveWrapper;Scrollable;ZStack;Elevation.
Non sono però già rimossi: la rimozione è pianificata per WordPress 7.4. La 7.2 rappresenta quindi il momento per censire le dipendenze e pianificare la sostituzione, senza descrivere la deprecazione come una rottura immediata. Inoltre, unstableFeaturedImageFlow viene sostituito da featuredImageFlow.
La roadmap comprende un Site Editor più estensibile e l’evoluzione del pannello documento tramite DataForm. Poiché l’esito finale non è ancora confermato, i plugin che aggiungono pannelli o controlli alla sidebar devono essere verificati nuovamente dopo RC1.
Database e Gallery Grid: verifiche mirate
In WordPress 7.2, wpdb rimuove per impostazione predefinita NO_BACKSLASH_ESCAPES dalla sessione database utilizzata da WordPress. L’impatto previsto è potenzialmente limitato e non va presentato come un’incompatibilità generalizzata.
Meritano comunque un controllo specifico:
- query SQL personalizzate;
- importer;
- integrazioni legacy sensibili a escaping e backslash.
Per intervenire attraverso incompatible_sql_modes è richiesto un drop-in db.php. Prima di adottare questa strada è necessario verificare se il progetto dipenda realmente dal comportamento precedente.
Il blocco Gallery riceve inoltre una variazione Grid. Flex rimane il comportamento predefinito e le gallerie già presenti non vengono convertite automaticamente. I test devono quindi coprire entrambe le configurazioni, soprattutto quando il tema applica regole CSS personalizzate al layout della galleria.
Checklist pre-aggiornamento per agenzie e freelance
- Censire lo stack: elencare tema, child theme, plugin, blocchi, componenti e integrazioni personalizzate.
- Creare uno staging rappresentativo: utilizzare configurazione, contenuti e personalizzazioni coerenti con il sito reale.
- Iniziare dalla Beta 1: usare la versione preliminare soltanto per test, mai in produzione.
- Analizzare la sanificazione HTML: cercare chiamate a
wp_kses*e test dipendenti dall’output esatto. - Verificare blocchi e CSS: controllare attributi
style, breakpoint, block supports, classi generate e resa visiva. - Censire le deprecazioni: individuare componenti interessati e pianificare la migrazione prima della rimozione prevista.
- Testare database e importer: concentrarsi sui flussi sensibili a escaping e backslash.
- Controllare l’editor: verificare sidebar, pannelli documento e personalizzazioni delle icone.
- Ripetere i test dopo RC1: confrontare i risultati con Field Guide e Dev Notes quando saranno disponibili.
- Attendere i vendor critici: verificare le dichiarazioni di compatibilità dei plugin commerciali e delle integrazioni indispensabili.
- Preparare il rilascio: procedere solo dopo backup, test in staging e predisposizione di un rollback.
La priorità va data ai progetti con temi fortemente personalizzati, librerie interne di blocchi, query custom, pannelli dell’editor estesi o integrazioni legacy. Nei siti meno personalizzati il numero di controlli può essere inferiore, ma deve comunque essere determinato dallo stack effettivo.
Un aggiornamento da valutare sullo stack reale
WordPress 7.2 richiede un approccio basato sulle dipendenze effettive del progetto, non su conclusioni generiche. Un audit preliminare permette di concentrare i test dove il cambiamento può avere conseguenze concrete e di separare le modifiche già implementate dalle funzionalità ancora in roadmap.
Per supporto tecnico nell’audit dello stack, nella preparazione dello staging, nei test di compatibilità e nella definizione del piano di rollback, Contattami per saperne di più.
AI Modified
Fonti
- What’s new for developers? (October 2026) (developer.wordpress.org)
- WordPress 7.2 – Make WordPress Core (make.wordpress.org)
- Roadmap to 7.2 – Make WordPress Core (make.wordpress.org)
Domande frequenti su WordPress 7.2
La release stabile è programmata per l’8 dicembre 2026. Il calendario indica Beta 1 il 20 ottobre e RC1, insieme al Field Guide, il 17 novembre 2026.
Soprattutto quelli con temi e blocchi personalizzati, query custom, importer, componenti dell’editor, SVG, sanificazione HTML o CSS strettamente dipendente dal markup generato. Non esiste però una criticità identica per tutti i siti.
Non è ancora certo. Il rifacimento basato sulla HTML API punta alla 7.2 o alla 7.3 in funzione dei test. La conferma dovrà arrivare con la documentazione del ciclo di rilascio.
No. Divider, ResponsiveWrapper, Scrollable, ZStack ed Elevation risultano deprecati dalla 7.2, mentre la rimozione è pianificata per WordPress 7.4.
Occorre creare uno staging rappresentativo, eseguire test funzionali e visivi dalla Beta 1, ripeterli dopo RC1 e verificare la documentazione disponibile. L’aggiornamento in produzione dovrebbe avvenire soltanto dopo backup, conferme sui componenti critici e predisposizione di un percorso di rollback.
