Le versioni di WordPress: cosa è cambiato release per release

Questa pagina risponde a una domanda sola: cosa è cambiato in WordPress, versione per versione, e quali di quei cambiamenti ti riguardano davvero. Al centro c’è una tabella con tutte le release dalla 6.0 in poi — data, cosa è cambiato in due righe, e se devi fare qualcosa. È la parte che conviene salvare nei preferiti.

Intorno alla tabella c’è il contesto che la rende utilizzabile: come funziona il ciclo di rilascio, perché le release minori si comportano in modo opposto alle major, e come si legge un changelog in cinque minuti senza doverlo capire tutto. Più avanti c’è la sezione più lunga, dedicata al salto dalla serie 6 alla 7.0: è il passaggio che spaventa chi è rimasto indietro, ed è quello che merita più spazio.

Una nota sul metodo, perché su questo argomento conta: ogni data e ogni funzionalità qui dentro viene dai post di annuncio ufficiali di WordPress.org e dai Field Guide per sviluppatori. Niente è ricostruito a memoria. Spiego alla fine perché lo scrivo.

Come funziona il ciclo di rilascio di WordPress

Prima della tabella serve il quadro, perché senza quello i numeri di versione sono solo numeri. WordPress ha due tipi di rilascio che si comportano in modo diverso e che vanno gestiti in modo opposto: le major (da 6.9 a 7.0, da 7.0 a 7.1) e le minori, dette anche point release (da 7.0.3 a 7.0.4).

Tre major all’anno, quando il calendario tiene

La roadmap ufficiale fissa per il 2026 l’obiettivo di tre major release, ed è il ritmo che il progetto insegue da diversi anni. Un ciclo di sviluppo dura circa quattro mesi, dalla prima riunione di definizione al rilascio.

Quello che succede davvero è leggermente diverso, e vale la pena saperlo perché cambia il modo in cui si pianifica:

• 2023: tre release — 6.2 a marzo, 6.3 ad agosto, 6.4 a novembre.
• 2024: tre release — 6.5 ad aprile, 6.6 a luglio, 6.7 a novembre.
• 2025: due release — 6.8 ad aprile e 6.9 a dicembre, con otto mesi di distanza.
• 2026: tre previste — 7.0 a maggio, 7.1 ad agosto, 7.2 pianificata per il 10 dicembre 2026.

La conseguenza pratica è semplice: «tre volte l’anno» è un ritmo di pianificazione, non una promessa. Se stai costruendo una routine di manutenzione, non metterla in calendario a date fisse: mettila come controllo trimestrale che comincia con «è uscita una major da quando ho guardato l’ultima volta?». Se la risposta è no, hai finito in trenta secondi.

Le cinque fasi di un ciclo, e l’unica che ti riguarda

Il manuale del core descrive cinque fasi: pianificazione e assegnazione dei responsabili, sviluppo, beta, release candidate, lancio. Non serve seguirle tutte, ma due meritano attenzione perché sono le uniche in cui puoi ancora fare qualcosa.

• Dalla beta in poi non entrano più funzionalità nuove. Si testano e si correggono bug. Quello che c’è dentro la release è già deciso.
• Dalla release candidate c’è il blocco delle stringhe e si lavora solo sulle regressioni introdotte nel ciclo. Da quel momento la release è, a tutti gli effetti, quella che uscirà.

La conseguenza operativa riguarda chi ha un tema su misura o plugin scritti apposta: la finestra buona per provare in staging è la release candidate, cioè settimane prima dell’uscita. Se trovi un problema lì, c’è ancora chi lo può correggere prima del lancio; se lo trovi dopo, sei tu a doverlo aggirare. Se invece il sito monta tema e plugin di terze parti e basta, non c’è ragione di seguire il ciclo: il post di annuncio arriva in tempo.

Le minori: niente da valutare, solo da installare

Una release minore non aggiunge file nuovi: contiene correzioni di bug e patch di sicurezza per problemi emersi dopo il rilascio della major. Non c’è niente da valutare, e il momento giusto per installarla è sempre «adesso».

C’è un dettaglio che si vede solo guardando l’elenco ufficiale delle versioni, e che secondo me è la cosa più rassicurante di tutto questo articolo. Il 12 agosto 2026 non è uscita solo la 7.0.4: lo stesso giorno sono uscite anche la 6.9.7, la 6.8.8, la 6.7.7, la 6.6.7, la 6.5.10, la 6.4.10 e la 6.3.10. Otto rilasci contemporanei, un unico annuncio, la stessa correzione portata indietro su tutti i rami ancora supportati.

Significa che anche un sito fermo a WordPress 6.4 da due anni continua a ricevere le patch di sicurezza del core, purché gli aggiornamenti automatici siano attivi. Non è un buon motivo per restare fermi — i plugin, il tema e la versione di PHP non hanno la stessa rete di protezione — ma è il motivo per cui un sito vecchio non è automaticamente un sito compromesso.

Cosa si aggiorna da solo dipende da quando è nato il sito

Qui c’è una cosa che quasi tutti danno per scontata e che invece varia da sito a sito. Secondo la documentazione ufficiale sugli aggiornamenti:

• Sui siti installati prima di WordPress 5.6, gli aggiornamenti automatici erano attivi solo per le release minori e per i file di traduzione.
• Sui siti installati da WordPress 5.6 in poi, gli aggiornamenti automatici sono attivi per impostazione predefinita anche per le major, a meno che WordPress non rilevi una copia di lavoro sotto controllo di versione.

Due siti affiancati, stesso hosting, stesso tema, possono quindi comportarsi in modo diverso davanti alla stessa major. È una delle poche cose in WordPress dove «di default» non basta come risposta: va guardato.

Il comportamento si legge e si imposta con la costante WP_AUTO_UPDATE_CORE in wp-config.php, che accetta tre valori:

// Tre valori possibili. Se ne sceglie UNO solo: la costante va definita una volta sola.

// Solo le minori: il valore consigliato per la maggior parte dei siti
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Tutto automatico, major comprese
define( 'WP_AUTO_UPDATE_CORE', true );

// Niente di automatico: da usare solo se qualcuno aggiorna a mano, davvero
define( 'WP_AUTO_UPDATE_CORE', false );

La regola che uso sui siti che seguo: minori automatiche, major programmate. Le prime sono sicurezza e la finestra fra la pubblicazione di una vulnerabilità e i primi tentativi di sfruttamento si misura in ore; le seconde vanno provate prima. Se non sai in che stato sono gli automatismi sul tuo sito, è il controllo che apre la checklist di sicurezza WordPress, e si verifica in un minuto da Bacheca > Aggiornamenti.

Tutte le versioni di WordPress dalla 6.0 in poi

La tabella parte dalla 6.0 di maggio 2022, cioè dal momento in cui l’editor a blocchi ha smesso di essere una novità ed è diventato il modo normale di costruire un sito. Prima di quella data i cambiamenti riguardano una WordPress che oggi non incontri più.

Come si legge: la colonna Cosa è cambiato davvero contiene solo le cose che l’annuncio ufficiale mette in evidenza, non l’elenco completo dei ticket — ogni release ne chiude centinaia. La colonna Devi fare qualcosa? è la risposta a «se il mio sito passa da questa versione, ho un lavoro da fare oltre a cliccare aggiorna?». Il numero di versione porta al post di annuncio ufficiale.

Due cose che si leggono meglio guardando la colonna dei temi. La prima: Twenty Twenty-Two non è arrivato con la 6.0, come si trova scritto in giro, ma con la 5.9 del gennaio 2022. La seconda, più interessante: l’ultimo tema predefinito nuovo è Twenty Twenty-Five, uscito con la 6.7 nel novembre 2024. Dopo una fase in cui ne arrivava uno quasi ogni anno — Twenty Twenty-Two con la 5.9, Twenty Twenty-Three con la 6.1, Twenty Twenty-Four con la 6.4 — da quasi due anni non ne esce uno nuovo. Se stai valutando su cosa costruire, questo dice più di molti articoli sull’argomento: il lavoro sui temi a blocchi si è spostato dagli esempi agli strumenti.

Cosa racconta la tabella letta tutta di fila

Presa una riga alla volta la tabella serve a rispondere a una domanda puntuale. Letta dal basso verso l’alto racconta un’altra cosa, che è utile a chi deve decidere se costruire una funzionalità su misura o aspettare che arrivi nel core.

La roadmap ufficiale divide il lavoro su WordPress in quattro fasi: editing più semplice (conclusa), personalizzazione, collaborazione e multilingua. Nella tabella si vedono distintamente:

• Dalla 6.0 alla 6.4 c’è la fase di personalizzazione. Site Editor che esce dalla beta e poi si unifica, varianti di stile, pattern, template, Block Hooks. Tutto ruota intorno al costruire il sito.
• Dalla 6.5 alla 6.7 il lavoro si sposta sugli strumenti per chi sviluppa. Font Library, Interactivity API, Block Bindings, Data Views, preset dei caratteri. Meno schermate nuove, più API — ed è la ragione per cui la 6.5 è la release che vale la pena conoscere anche a due anni di distanza.
• La 6.8 è una pausa dichiarata: bcrypt, speculative loading, rifiniture. Succede, e non è un difetto.
• Dalla 6.9 in poi c’è la fase della collaborazione — le note, le menzioni, i commenti ancorati al testo — con l’integrazione dell’AI che le cresce accanto. La collaborazione in tempo reale, quella con più cursori sullo stesso documento, non è ancora arrivata: è stata provata a lungo durante il ciclo della 7.1, ma nella release finale non è attiva.

La quarta fase, il multilingua nel core, non è cominciata. Detto in termini pratici: se hai un sito in più lingue, al momento è ancora e soltanto un lavoro da plugin, e lo sarà per un po’.

Come sapere quale versione hai

Serve per usare la tabella, e sono tre posti diversi con tre risposte diverse:

• Bacheca > Home, riquadro «Un’occhiata». In fondo al riquadro c’è una riga che dice su quale versione di WordPress stai girando e quale tema è attivo. È il modo più rapido.
• Bacheca > Aggiornamenti. Stessa informazione, più la versione disponibile e lo stato degli aggiornamenti automatici.
• Strumenti > Salute del sito > Info. La sezione WordPress ha la versione, la sezione Server ha quella di PHP. È l’unico posto dove trovi entrambe, ed è quello da aprire prima di pianificare un salto di versione.

Come capire in cinque minuti se una release ti riguarda

Ogni major chiude centinaia di ticket. Leggerli tutti non ha senso e nessuno lo fa. Quello che ha senso è sapere dove guardare e in che ordine: sono tre documenti ufficiali, pubblicati per ogni release, e si guardano dal più leggero al più tecnico.

1. Il post di annuncio su wordpress.org/news. Due o tre minuti. Serve a rispondere a «cambia qualcosa per chi usa il sito?». Se sei un utente e non uno sviluppatore, spesso finisce qui.
2. Il Field Guide su make.wordpress.org/core. Viene pubblicato durante la fase di release candidate e raccoglie tutte le note per sviluppatori uscite durante la beta. È il documento dove stanno i breaking change, ed è quello che quasi nessuno legge. Due minuti bastano: si scorrono i titoli.
3. Le singole dev note, linkate dal Field Guide. Si aprono solo quelle che riguardano una cosa che il tuo sito usa davvero.

Mentre scorri, le domande sono quattro, in quest’ordine, perché è l’ordine in cui bloccano il lavoro:

• Cambiano i requisiti minimi? Se una release alza il minimo di PHP o del database, quello viene prima di tutto il resto ed è un lavoro sull’hosting, non su WordPress. È successo con la 6.3 e con la 7.0.
• C’è un breaking change che tocca l’editor o le API dei blocchi? Se sì, lo staging non è facoltativo: è il punto dove i plugin di terze parti si rompono.
• È stata rimossa una funzione o un hook che il mio codice usa? Si risponde in due minuti cercando il nome dell’hook dentro il tema e i plugin personalizzati.
• Il resto sono funzionalità nuove? Allora possono aspettare il momento buono. Nessuno si è mai fatto male rimandando di tre settimane l’accesso a un blocco nuovo.

Un esempio con la release più recente, per far vedere che sono davvero cinque minuti. Applicando le quattro domande a WordPress 7.1:

1. Cambiano i requisiti? No. La 7.1 non tocca i minimi di PHP o del database. Domanda chiusa.
2. Breaking change sull’editor? Sì, ed è grosso: l’editor dei post diventa sempre iframed, senza possibilità di tornare indietro. Se hai un page builder o campi personalizzati, la risposta ti ha già detto che serve lo staging.
3. Hook rimossi? Sì, tre: wp_image_editors, image_memory_limit e image_make_intermediate_size non vengono più eseguiti sul percorso lato browser. Cercarli dentro il tema e i plugin su misura costa due minuti.
4. Il resto? Blocchi Tab e Playlist, stili responsivi, note con menzioni. Roba buona che può aspettare.

Cinque minuti, e sai se l’aggiornamento è una cosa da martedì sera o un lavoro da programmare. Il ragionamento completo su quella release, con il dettaglio di cosa si rompe e come si corregge, è in le novità di WordPress 7.1 e cosa può rompersi.

C’è un quinto controllo, che vale per tutto quello che leggi sulle release e non solo per le fonti ufficiali: se il nome di una funzionalità non compare nel post di annuncio, quella funzionalità non è in quella release. Sembra ovvio ed è la difesa più efficace che conosco, perché non richiede di sapere cosa c’è dentro WordPress: richiede solo di aprire una pagina e usare la ricerca del browser.

Il salto da WordPress 6.x a 7.0

Se il tuo sito è fermo da qualche parte nella serie 6, il salto che conta non è l’ultima release uscita: è la 7.0 «Armstrong» del 20 maggio 2026. È la release che ha cambiato le fondamenta, ed è quella che decide se l’aggiornamento sarà una serata o un progetto.

Cosa ha portato la 7.0

Le novità visibili sono quattro, e cambiano l’aspetto del pannello prima ancora del sito:

• L’intelligenza artificiale entra nel core. Non come funzione che scrive testi al posto tuo, ma come client: un’interfaccia unica che permette ai plugin di dialogare con i modelli generativi restando indipendenti dal fornitore, insieme alla Abilities API introdotta con la 6.9. Se non installi niente che la usi, non te ne accorgi.
• La bacheca è stata rifatta. Colori, transizioni e la palette dei comandi (⌘K su Mac, Ctrl+K altrove) disponibile ovunque nel pannello. La palette non è nuova — esiste dalla 6.3 — ma fino alla 7.0 viveva solo dentro gli editor.
• Gestione dei caratteri e delle revisioni. Una pagina dedicata per installare e organizzare i font, e uno scorrimento visivo fra le revisioni con i segnaposto delle modifiche.
• Blocchi e controlli nuovi: Breadcrumb, Icone, galleria con lightbox a scorrimento, visibilità per tipo di dispositivo senza toccare il CSS, sovrapposizioni di menu costruibili a blocchi, pattern scollegabili, e CSS personalizzato applicabile al singolo blocco dentro l’articolo.

Per chi sviluppa c’è una novità che vale da sola il paragrafo: i blocchi si possono registrare interamente lato server, in PHP, senza passare da un processo di build JavaScript. È il cambiamento che abbassa di più la barriera d’ingresso per chi scrive plugin su misura.

Il requisito che decide tutto: PHP 7.4

La 7.0 alza il minimo di PHP a 7.4, abbandonando il supporto a 7.2 e 7.3. È l’unico punto di questo articolo che può bloccare un aggiornamento prima ancora di cominciarlo, ed è anche il più facile da verificare: Strumenti > Salute del sito > Info > Server, trenta secondi.

Il minimo però non è la raccomandazione. Il criterio che non invecchia è questo: la versione di PHP dev’essere fra quelle che ricevono ancora aggiornamenti di sicurezza, e possibilmente fra quelle che WordPress raccomanda. Alla data di questo articolo — agosto 2026 — la raccomandazione ufficiale è PHP 8.3 o superiore con MariaDB 10.11+ o MySQL 8.0+; WordPress continua a funzionare su PHP 7.4, che però è fuori supporto da tempo. I numeri cambiano, quindi conviene leggerli alla fonte: la pagina ufficiale dei requisiti è aggiornata a ogni giro.

Se sei sotto il minimo, l’aggiornamento di PHP viene prima e si fa dal pannello dell’hosting, non da WordPress. Su un VPS il passaggio è a livello di PHP-FPM: nella guida all’installazione e alla configurazione ho descritto com’è fatto lo stack sotto WordPress e dove si mette le mani.

L’iframe dell’editor: una mossa sola, fatta in tre release

Questa è la ragione principale per cui una tabella storica serve, e non si capisce guardando una release alla volta. Il cambiamento più impegnativo degli ultimi due anni è stato spalmato su tre versioni consecutive:

• 6.9 ha richiesto apiVersion 3 per i blocchi nuovi o aggiornati, con un avviso nella console per gli altri. Era il preavviso.
• 7.0 ha attivato l’iframe dell’editor quando tutti i blocchi in gioco usano la versione 3 delle API, e lo ha tolto negli altri casi per compatibilità. Era la transizione.
• 7.1 ha reso l’iframe incondizionato, per qualunque tema e qualunque blocco, meta box vecchio stile compresi. Nessun modo previsto per tornare indietro.

La conseguenza pratica: se un plugin è fermo a prima di dicembre 2025 e tocca l’editor, non ha visto nessuno dei tre passaggi. Il guasto tipico non compare nella console — il JavaScript cerca gli elementi nel documento sbagliato e semplicemente non li trova — e si manifesta come «quel pulsante non fa più niente». I dettagli tecnici e la correzione stanno nell’approfondimento sull’aggiornamento a WordPress 7.1.

Una cosa da cercare nei temi datati

Con la 7.0 il supporto tema html5 per script è stato deprecato e rimosso. Se il tema è vecchio, la riga da cercare in functions.php è questa:

add_theme_support( 'html5', array( 'search-form', 'comment-form', 'gallery', 'script' ) );

La voce 'script' dalla 7.0 non ha più effetto. Non produce un errore e non rompe la pagina: semplicemente non fa più niente, e va tolta quando si mette mano al tema. È l’esempio tipico di cosa si trova nel Field Guide e non nel post di annuncio.

Cosa provare in staging su un salto alla serie 7

Sono quattro prove, e vengono dalle note per sviluppatori della 7.0, non dal buon senso. Si fanno in mezz’ora e coprono i punti che quella release ha effettivamente toccato:

• Apri un articolo complicato in modifica, di quelli con i campi personalizzati e le meta box che usi davvero, e clicca i pulsanti aggiunti dai plugin. È qui che si manifesta il passaggio all’iframe.
• Guarda il riquadro di pubblicazione. I plugin che ci infilano pulsanti propri sono la fonte di problemi di impaginazione già segnalata per questa release: si vede a occhio, subito.
• Prova un tipo di contenuto personalizzato. La logica dei Block Hooks è cambiata, e le integrazioni che inseriscono blocchi in automatico vanno riviste.
• Fai un giro nella bacheca rifatta con un utente che non sia amministratore. I plugin che aggiungono voci di menu o schermate proprie sono quelli che si accorgono di più del cambio di aspetto.

Non serve passare per le versioni intermedie

Domanda che ricevo spesso: se sono sulla 6.4, devo installare la 6.5, poi la 6.6, e così via? No. WordPress aggiorna direttamente all’ultima versione disponibile, e le migrazioni del database vengono eseguite in sequenza da sole.

Il punto è un altro, ed è il motivo per cui la domanda continua a essere sensata: i cambiamenti non si sommano nel database, si sommano nell’ecosistema. Tutte le incompatibilità di nove release arrivano insieme, nello stesso pomeriggio, e i plugin fermi da anni sono il punto in cui il lavoro si complica. Per questo un salto lungo si tratta come un progetto e non come un aggiornamento: inventario dei plugin fatto prima, staging, tempo previsto per sistemare quello che non passa.

Se il sito è fermo da anni

Il caso più comune non è il sito abbandonato: è il sito che funziona, che nessuno vuole toccare, e su cui l’aggiornamento viene rimandato ogni volta di un mese. L’ordine che riduce i rischi è sempre lo stesso, e le prime due voci sono quelle che si saltano più spesso.

1. La versione di PHP, prima di tutto il resto. Se è sotto il minimo richiesto dalla versione di WordPress a cui vuoi arrivare, l’aggiornamento non parte proprio. Si fa dall’hosting, e a volte richiede di sistemare del codice.
2. Un backup che hai provato a ripristinare. Un backup mai ripristinato è un’ipotesi, non una rete.
3. L’inventario dei plugin. Per ciascuno: data dell’ultimo aggiornamento e compatibilità dichiarata. Quelli fermi da più di dodici mesi vanno decisi prima, non durante.
4. Lo staging. Su un salto lungo non è una precauzione, è il posto dove si fa il lavoro.
5. L’aggiornamento vero e i controlli dopo.

La procedura completa — backup verificato, controllo di compatibilità, staging, controlli post-aggiornamento — non la riscrivo qui perché esiste già ed è dettagliata: è nella guida all’aggiornamento di WordPress. Questa pagina dice cosa è cambiato; quella dice come si aggiorna.

E la parte che conta davvero viene dopo: fare in modo che non ricapiti. Leggere il changelog dell’ultima release è una voce da venti minuti a trimestre nella checklist di manutenzione WordPress. Venti minuti ogni tre mesi contro un pomeriggio ogni tre anni non è lo stesso lavoro distribuito diversamente: è meno lavoro, perché ogni singolo passaggio è piccolo abbastanza da poter essere annullato.

Un caso a parte sono le immagini, perché con la 7.1 il modo in cui WordPress le elabora è cambiato in profondità: se sul sito hai un plugin di ottimizzazione o una pipeline costruita a mano, quella è la prima cosa da riprovare dopo un salto lungo. Il contesto — formati, conversione, quando conviene farla e dove — è in lazy loading, caching e minificazione.

Da dove vengono queste date

Date, nomi delle release e funzionalità di questa pagina vengono da quattro fonti ufficiali, tutte pubbliche e tutte controllabili in pochi minuti:

• L’elenco ufficiale delle versioni di WordPress, che riporta per ogni release la data esatta, il changelog e il link all’annuncio. È da lì che vengono tutte le date della tabella, comprese quelle degli otto rilasci minori simultanei del 12 agosto 2026.
• I post di annuncio nell’archivio dei rilasci, uno per versione: sono la fonte dei nomi delle funzionalità.
• I Field Guide per sviluppatori, da cui vengono i requisiti di PHP, i breaking change e le rimozioni.
• La pagina dei requisiti e la roadmap per le versioni raccomandate e per il calendario dei rilasci futuri.

Lo scrivo per un motivo concreto. Sulle release di WordPress circola parecchio materiale che descrive funzionalità che non sono mai esistite, ed è impossibile riconoscerlo a colpo d’occhio: è scritto bene, ha i numeri di versione giusti, la struttura giusta e il tono giusto. Cambia solo il contenuto.

Su questo blog quel materiale c’era. Fino ad agosto 2026 le versioni da 6.0 a 6.8 avevano una pagina ciascuna, e otto di quelle nove pagine descrivevano funzionalità inventate. Le ho verificate una per una contro gli annunci ufficiali, e sono state sostituite da questa pagina. Preferisco dirlo qui piuttosto che lasciare che qualcuno se ne accorga da solo: se hai letto una di quelle pagine e ti sei fatto un’idea di cosa contenesse una release, l’idea giusta è nella tabella qui sopra.

La difesa contro tutto questo è la stessa che vale per me: i nomi delle funzionalità si controllano sull’annuncio ufficiale. Se una cosa non è lì, non è nella release.

Domande frequenti

Se l’aggiornamento del core è la cosa che rimandi da mesi perché nessuno vuole essere quello che rompe il sito, è esattamente il lavoro che faccio: verifica della versione e dei requisiti, prova in staging, aggiornamento, controlli dopo, e la lista scritta di cosa è stato toccato. Scrivimi e ne parliamo, oppure guarda come funziona un piano di aggiornamenti e manutenzione.