Aggiornare WordPress 7 conviene? La 7.1.2 subito, il resto con calma

Sì, ma sono due decisioni diverse, e vanno prese in due tempi. La 7.1.2 uscita il 22 settembre chiude una falla di gravità critica: si installa oggi, su qualunque sito, senza aspettare nessuno. Il passaggio da una 6.x alla 7 è un'altra cosa: si prova prima su una copia, perché la dashboard è stata rifatta e i plugin che ci si appoggiano non sempre reggono.

Lo scrivo perché nelle ultime settimane la domanda mi è arrivata nella forma sbagliata: «aggiorno o no?», come se fosse un interruttore solo. WordPress in quattro mesi ha pubblicato due major e una serie di correzioni di sicurezza, e mettere tutto nello stesso sacco porta a due errori opposti: rinviare la patch per paura della nuova versione, oppure fare il salto di major di venerdì sera perché «tanto è solo un aggiornamento».

La patch di sicurezza arriva anche a chi resta sulla 6, quindi non hai scuse

La 7.1.2 corregge una vulnerabilità che, in certe condizioni di server e di tema, permette a un utente non autenticato di far eseguire codice PHP sul sito. È il tipo di falla peggiore che esista per un CMS, e il team di WordPress la classifica come critica e chiede di aggiornare subito.

Il dettaglio che cambia la decisione: la correzione è stata riportata su tutti i rami ancora idonei alle patch di sicurezza, fino alla 4.7. Quindi un sito rimasto su una 6.x riceve la sua correzione sul ramo 6.x, senza dover passare alla 7. La sicurezza e la nuova versione sono due binari separati, e chi tiene attivi gli aggiornamenti automatici in background sui rilasci minori ha già ricevuto la patch senza fare niente.

Il controllo che faccio io sui siti che seguo: apro Bacheca, poi Aggiornamenti, e leggo il numero di versione. Se è la 7.1.2, o l'ultima minor del ramo che il sito ha, sono a posto. Se gli aggiornamenti automatici sono disattivati, li riaccendo almeno per le minor: è la modifica con il miglior rapporto fra tempo speso e rischio tolto che conosco.

Due major in quattro mesi: cosa è cambiato davvero

La 7.0, uscita il 20 maggio 2026, è la versione che si vede. Dashboard ridisegnata, una command palette che si apre con Ctrl+K o ⌘K, blocchi nuovi (galleria con lightbox, breadcrumb, icone) e la possibilità di nascondere o mostrare un blocco per dispositivo senza toccare il CSS. Sotto, la novità grossa: un client AI nel core, con un hub centrale in cui collegare servizi esterni tramite preset, e un'API con cui plugin e temi possono esporre le proprie funzioni a quel client.

La 7.1, del 19 agosto 2026, è la versione che si sente. Compressione, ridimensionamento e miniature delle immagini adesso si fanno nel browser, via WebAssembly, prima del caricamento: il server smette di macinare foto da otto megabyte. Arrivano il supporto nativo ad AVIF e HEIC, i controlli responsive dentro il Site Editor, un blocco Tabs e uno Playlist. E l'editor degli articoli è ora dentro un iframe per tutti i temi, non solo per quelli a blocchi: tienilo a mente, torna fra poco.

In mezzo, le correzioni: 7.0.3 e 7.0.4 in agosto, la 7.1.1 del 17 settembre con 11 correzioni di sicurezza e 36 di bug, la 7.1.2 del 22. Nessuna di queste va provata in staging. Si installano.

Il salto di major si prova su una copia, e quello che si rompe è la dashboard

Nei passaggi di major che ho fatto, il frontend è quasi sempre la parte che regge meglio: il tema mostra le pagine come prima e un visitatore non nota niente. Si rompe dietro. I plugin che disegnano pannelli in amministrazione, che aggiungono pulsanti all'editor o che iniettano script nella pagina di modifica danno per scontata una struttura che la 7.0 ha cambiato e che la 7.1 ha chiuso dentro un iframe. Un plugin scritto tre anni fa e mai aggiornato può smettere di mostrare i suoi campi, o mostrarli con lo stile sbagliato, senza dare nessun errore visibile.

Il metodo, che è lo stesso da anni e che la 7 non cambia:

• una copia del sito su un sottodominio o in locale, con la stessa versione di PHP del server di produzione;
• prima si aggiorna il core, poi si aprono le dieci schermate che chi lavora sul sito usa davvero: modifica articolo, modifica pagina, media, il pannello del plugin dei form, quello dell'e-commerce se c'è;
• poi si aggiornano i plugin uno alla volta, guardando il log degli errori PHP dopo ciascuno;
• solo alla fine si porta tutto in produzione, con un backup fatto un minuto prima.

Chi non ha uno staging non ha un sito troppo semplice per averlo: ha un sito che verrà aggiornato alla cieca. Sui piani hosting recenti la copia si crea in pochi clic, e se il tuo non lo permette la domanda da fare a chi lo gestisce è perché.

L'AI nel core è una decisione in più, non una funzione in più

Il client AI della 7.0 da solo non fa niente: va collegato a un provider esterno, e quel collegamento ha una chiave, un contratto e una fattura. Le domande che deve farsi chi ha il sito sono queste, prima che qualcuno nel team clicchi «connetti»:

• quale servizio si collega, e dove finiscono i testi e le immagini che gli si mandano;
• chi paga i token, e chi vede il conto a fine mese;
• quali utenti del sito possono usarlo, e per fare cosa.

La mia posizione è che la funzione vada lasciata scollegata finché queste tre righe non hanno una risposta scritta. Non è sfiducia nello strumento: è che un connettore acceso da un redattore con la propria chiave personale è il classico costo che nessuno ha approvato e che si scopre a dicembre. Se poi il sito deve davvero usare l'AI per qualcosa di preciso, quello è un progetto di AI applicata con un perimetro suo, non una spunta nella dashboard.

Cosa decidere adesso, se il sito è tuo

La 7.2 è già in programma per dicembre. Restare sulla 6 per prudenza significa trovarsi, a fine anno, con due major da saltare in una volta sola, ed è lo scenario in cui le cose si rompono davvero. Il piano che consiglio è corto:

1. Oggi: verificare che il sito abbia la 7.1.2, o l'ultima minor del suo ramo. Se no, aggiornare. Se gli aggiornamenti automatici delle minor sono spenti, riaccenderli.
2. Nelle prossime settimane: chiedere a chi segue il sito una prova della 7.1 su staging, con l'elenco delle schermate da controllare scritto da chi il sito lo usa ogni giorno. Il preventivo di quel lavoro dovrebbe essere di ore, non di giorni; se è di giorni, il motivo va spiegato, e di solito è un plugin abbandonato da sostituire.
3. Prima di collegare qualunque provider AI: le tre domande di sopra, su carta.

Se non c'è nessuno che segue il sito, questo è il momento in cui te ne accorgi, ed è il tema di un altro articolo. Tenere aggiornato un WordPress è la parte noiosa del lavoro di sviluppo web, e il 22 settembre la parte noiosa è quella che ha fatto la differenza fra un sito corretto in silenzio e uno esposto.