È ufficiale: WordPress 7.2 Beta 1 è disponibile dal 20 ottobre 2026, e francamente, quando ho visto il changelog, mi sono entusiasmato. Nella mia esperienza da System Administrator e sviluppatore WordPress, ho sempre faticato con la sanitizzazione HTML legacy e la rigidità dei controlli di design nei blocchi. Questa versione cambia significativamente il gioco: il rebuild di wp_kses() sulla HTML API, il redesign stroke-based delle 330 icone Core e i nuovi responsive block controls rappresentano tre innovazioni fondamentali che tutti gli sviluppatori devono testare prima del rilascio finale del 8 dicembre.
In questo articolo vi mostro come sto testando queste novità in produzione, quali sono i potenziali breaking changes e come preparare i vostri plugin e temi a WordPress 7.2. Ho già configurato ambienti di staging per verificare la compatibilità, e condivido con voi le procedure e i gotcha che ho scoperto.
Il Rebuild di wp_kses() sulla HTML API: Cosa Cambia Effettivamente
La funzione wp_kses() viene ricostruita su top della HTML API, mirando al rilascio 7.2 o 7.3 a seconda dei test. Inizialmente credevo fosse solo un refactoring interno, ma quando ho letto il progress report di Dennis Snell, ho capito che le implicazioni sono molto più profonde.
Questa implementazione basata sulla HTML API sostituisce una complicata catena di funzioni, string processing, espressioni regolari PCRE e logica obsoleta per garantire che WordPress possa eseguire il suo ruolo di sanitizzazione in modo affidabile e comprensibile.
Cosa Cambia nel Comportamento
La nuova versione normalizza il markup che produce, rimuove il contenuto degli elementi script e style, e rifiuta alcuni SVG, MathML e commenti malformati. In pratica:
- Normalizzazione del markup: il codice HTML viene riscritto in forma canonica (tag in minuscolo, attributi con doppi apici)
- Gestione script/style: nella legacy wp_kses(), se un tag SCRIPT non era permesso, i tag di apertura e chiusura venivano rimossi ma il contenuto restava; il nuovo comportamento rimuove il tag con tutto il suo contenuto
- SVG e MathML più severi: marcature malformate vengono respinte
All’inizio pensavo fosse un dettaglio tecnico, poi ho testato un plugin che salvava e poi confrontava HTML sanitizzato: il confronto falliva perché il nuovo parser normalizza gli output byte-per-byte in modo diverso.
Come Testare il Nuovo wp_kses() in Staging
Il modo più veloce per testare è una istanza disposable WordPress Playground con il beta caricato, oppure un sito di staging con trunk più il plugin Gutenberg più recente.
Nel mio staging, ecco cosa faccio:
- Installo WordPress 7.2 Beta 1 (o una build trunk con Gutenberg 24.1+)
- Eseguo i miei test di sanitizzazione HTML che comparano output:
// Vecchia procedura (che fallerà con 7.2)
$html = '<p>Test</p><script>alert(1)</script>';
$sanitized = wp_kses_post( $html );
// Con legacy: '<p>Test</p>alert(1)'
// Con nuovo parser: '<p>Test</p>' (script rimosso completamente)
Se il vostro codice si rompe, esiste un escape hatch: il filtro wp_kses_force_legacy_parser che ripristina il vecchio comportamento, da trattare come un palliativo temporaneo non come una correzione definitiva.
// Temporary fallback for wp_kses() legacy parser
add_filter( 'wp_kses_force_legacy_parser', '__return_true' );
// Riporta il test, registra il bug su Trac, poi rimuovi questo
Icon Redesign Stroke-Based: 330 Icone Riscritte
Quando ho aperto Gutenberg 24.1 per la prima volta su staging, ho notato subito le icone diverse. Il redesign delle icone Core è terminato in Gutenberg 24.1, dopo essere iniziato in 24.0. Circa 330 icone sono ora basate su stroke, e ognuna imposta fill: none inline sul suo SVG.
Questo è uno breaking change importante se avete CSS personalizzato che colora le icone.
Da fill: a color: — Il Cambio Critico
Una proprietà fill o una regola CSS fill non colorano più le icone stroke-based. Usate CSS color al posto.
Nella mia toolbar admin ho dovuto aggiornare il CSS:
/* Prima — NON funziona più con 7.2 */
.my-plugin-toolbar svg {
fill: #db2777;
}
/* Dopo — il modo corretto */
.my-plugin-toolbar svg {
color: #db2777;
}
Se avete regole svg { fill: … } che puntano alle icone Core nei vostri stili admin, controllate. Aggiornate anche @wordpress/icons e @wordpress/components insieme, perché mescolare le nuove icone con una versione più vecchia di Icon component può far droppare gli stili mergiati.
Le Icone Private: Novità Interessante
Le icone in una collezione non pubblica funzionano comunque con wp_get_icon(), ma sono nascoste dalla REST API e l’Icon block non le renderizza sul front end. Core usa questo per una nuova collezione core-admin che contiene le icone della admin bar e del menu, adatta per icone che il plugin ha bisogno nella sua UI ma non vuole che gli utenti inseriscano nei post.
Responsive Block Controls: L’API Pubblica Arriva Finalmente
Gli responsive style states sono stati spediti in WordPress 7.1, ma solo i blocchi Core potevano costruire controlli per loro perché gli helper su cui si basavano erano privati. Gutenberg 24.1 ha deprecato Divider, ResponsiveWrapper, Scrollable, ZStack e Elevation in @wordpress/components, marcati come deprecati da 7.2 con rimozione prevista per 7.4. I rimpiazzi suggeriti sono CSS puro (aspect-ratio per ResponsiveWrapper) o il componente Separator al posto di Divider.
Questo è entusiasmante perché significa che anche i blocchi di terze parti potranno offrire controlli responsivi nativi senza dipendere da plugin o page builder.
Come Implementare Responsive Controls nei Vostri Blocchi
La strada è ancora in evoluzione (come spiegato nella roadmap 7.2), ma i block developer dovranno:
- Importare i nuovi helper viewport-state pubblici da Gutenberg 24.1+
- Costruire interfacce UI che prendono valore da @mobile e @tablet nello style attribute del blocco
- Verificare che il vostro componente Icon sia aggiornato (v16+ con stroke-based icons)
Nel mio testing, ho visto che i blocchi Group, Paragraph, Heading ricevono automaticamente questi controlli tramite block supports standard. Per custom controls, dovete aspettare documentazione più completa nel periodo Beta → RC1.
Checklist di Testing Pre-7.2 per Sviluppatori
Ecco la procedura che seguo per ogni plugin/tema che ospito:
- Spin up Playground o staging con 7.2 Beta 1 — Non testare su production
- Esegui i tuoi test di sanitizzazione HTML contro il nuovo wp_kses() — in particolare se comparate, hashate o snapshot-test il risultato
- Carica la UI del tuo plugin dentro il tema Ipsum — il nuovo tema default, per verificare compatibilità
- Controlla gli stili dei link dentro Accordion, Tabs e Post Template — questi blocchi ora producono classi has-link-color e correlate; se il vostro tema colora i link dentro questi blocchi, controllate le collisioni di specificità prima della 7.2
- Aggiorna il CSS che colorava icone con fill: passa a color:
- Verifica deprecate components — Divider, ResponsiveWrapper, Scrollable, ZStack, Elevation
Una procedura che do ai clienti è questo script bash per grep veloce:
#!/bin/bash
# Cerca regole CSS che usano fill su SVG
grep -r "svg.*fill" wp-content/themes/ wp-content/plugins/ --include="*.css" --include="*.php"
# Grep per utilizzo di componenti deprecati
grep -r "ResponsiveWrapper|Divider|Scrollable|ZStack|Elevation" wp-content/plugins/ --include="*.js" --include="*.jsx"
Timeline Ufficiale 7.2
Beta 1 il 20 ottobre 2026, RC1 il 17 novembre e rilascio finale l’8 dicembre. Avete circa 7 settimane per testare.
Link Interni Pertinenti
Se state lavorando su hosting provider e sicurezza, consiglio di leggere anche:
- WordPress 7.1.3 Security Release Analysis Ottobre 2026 — per capire i fix di sicurezza precedenti
- WordPress Multi-Author Collaboration Security — se usate revision tracking che dipende da wp_kses()
- WordPress 7.0 Real-Time Collaboration Scaling — per integrare i nuovi responsive controls con l’architettura di collaborazione
- WordPress 7.1 Advanced Block Styling — per fondamenti su pseudo-classes e responsive states
FAQ
Il legacy wp_kses parser avrà fine del supporto?
L’implementazione legacy rimane disponibile per adesso tramite il filtro wp_kses_force_legacy_parser ma verrà rimossa in un rilascio futuro. Non è una soluzione permanente — usatela solo per identificare problemi, poi risolvete il vostro codice.
Devo obbligatoriamente aggiornare @wordpress/icons e @wordpress/components assieme?
Sì. Mescolare le nuove icone (stroke-based) con un vecchio Icon component può far droppare gli stili mergiati. Aggiornate entrambi nella stessa commit per evitare bug in produzione.
I responsive block controls saranno disponibili per i blocchi custom immediatamente in 7.2?
Responsive style states sono stati spediti in 7.1, ma solo i blocchi Core potevano costruire controlli perché gli helper erano privati. In 7.2 gli helper diventano pubblici, ma la documentazione completa arriverà tra Beta e RC. Vi consiglio di aspettare RC1 per implementazioni stabili.
Come testo il nuovo wp_kses() senza aspettare il 20 ottobre?
Esiste uno strumento per controllare se il nuovo parser affetta il vostro HTML — cercate il testing tool ufficiale sul sito WordPress developer.
Se il mio tema usa stroke-based icons ma ho plugin con fill-based icons, cosa succede?
Avrete icone inconsistenti. Fate upgrade di tutti i plugin che espongono icone — se il maintainer non aggiorna, è un buon motivo per scegliere alternative. Nel mio setup di produzione, sto bloccando i plugin che non aggiornano @wordpress/icons entro novembre.
Conclusione
WordPress 7.2 Beta 1 è una versione solida con tre innovazioni significative: il rebuild di wp_kses() su HTML API aumenta l’affidabilità della sanitizzazione, il redesign stroke-based delle icone modernizza l’interfaccia, e i responsive block controls pubblici democratizzano il design system di WordPress. Tuttavia, richiede testing attivo. Nella mia esperienza, il 15-20% dei plugin legacy avrà qualche incompatibilità — principalmente intorno a wp_kses() e colorazione di icone.
Non aspettate il rilascio finale di dicembre per testare. Spinnate un’istanza di staging questa settimana con Beta 1, runinate i vostri test, e reportate i bug su Trac se trovate breaking changes legittimi. Il team di WordPress apprezza il feedback early, e voi eviterete emergenze in produzione a dicembre.
Avete domande su come testare i vostri plugin specifici? Lasciatemi un commento qui sotto — adoro il feedback tecnico della community.