La versione è ancora in sviluppo
Al 15 ottobre il calendario ufficiale indica WordPress 7.2 Beta 1 per il 20 ottobre alle 15:00 UTC e la versione finale per l’8 dicembre. È l’obiettivo attuale del progetto, non una garanzia che date o ambito non cambino. Il team considera 7.2 l’ultima release principale del 2026 e prevede di includere anche un nuovo tema predefinito.
Per chi gestisce siti è il momento di preparare l’ambiente di test, non di aggiornare la produzione. Prima della Beta 1 lo sviluppo continua; beta e release candidate servono a trovare problemi e non sono build per i normali siti live. Seguite la pagina della release e le note per gli sviluppatori: la scelta di aggiornamento stabile si farà dopo la pubblicazione finale.
È già documentata una modifica di compatibilità SQL
Una nota per sviluppatori descrive una modifica concreta: WordPress 7.2 considera incompatibile la modalità MySQL `NO_BACKSLASH_ESCAPES` e la rimuove dalle modalità della sessione alla connessione. WordPress usa la barra inversa per proteggere caratteri speciali nelle query; con questa modalità il database la interpreta diversamente. La modifica riguarda la sessione WordPress, non le impostazioni globali del server.
Il team Core dice che la maggior parte dei siti non noterà differenze, ma avverte che WordPress potrebbe non funzionare correttamente se la modalità resta attiva. Chi ne dipende per scelta dovrebbe chiedere una revisione tecnica. Il filtro documentato va applicato in una configurazione caricata prima dei plugin ordinari, perché la connessione avviene prima. Non è un motivo per cambiare le impostazioni SQL di ogni server.
Gutenberg non equivale a una promessa per il core
Gutenberg ha un proprio calendario e le sue note di versione possono riguardare lavori che non saranno necessariamente inclusi in una specifica release WordPress. La roadmap 7.2 cita un nuovo tema e dice che le funzioni saranno considerate quando sufficientemente pronte, ma non è un elenco definitivo delle modifiche dell’editor. Per temi e plugin saranno più affidabili le note beta e la guida finale.
Per le agenzie la domanda utile non è cosa contenga Gutenberg oggi, ma quale codice sia effettivamente presente nella beta e nella versione finale di 7.2. Confrontate la build con i plugin, il tema, le estensioni dell’editor, i blocchi personalizzati, la versione PHP e l’hosting di ogni cliente. Provate il sito reale invece di affidarvi soltanto a un’etichetta di compatibilità.
Una checklist di preparazione sicura
Create uno staging con backup aggiornati e una procedura di ripristino verificata. Annotate versioni di WordPress, PHP, database e plugin, oltre al codice personalizzato che modifica l’SQL o l’editor. Quando arriva la Beta 1, testate un sito rappresentativo: modifica e pubblicazione, anteprime, template, attività pianificate, moduli, pagamenti o iscrizioni e log.
Lasciate la produzione su una versione stabile supportata finché WordPress non rilascia 7.2 finale e i vostri test non passano. Durante la beta inviate segnalazioni riproducibili, con ambiente e passaggi chiari. Dopo il rilascio aggiornate prima lo staging, verificate backup e rollback e poi pianificate la produzione secondo rischio e manutenzione del singolo sito. Non promettete compatibilità prima dei test.
Fonti e approfondimenti
Vuoi segnalare un errore o suggerire una fonte? Contatta la redazione.
