WordPress 7.1: cosa cambia davvero e se devi aggiornare subito

WordPress 7.1 «Mary Lou» è uscita il 19 agosto 2026. Se sei arrivato qui è probabile che la domanda non sia «quali sono tutte le novità»: è «devo aggiornare adesso o posso aspettare, e cosa mi si rompe?». Questo articolo risponde a quella. Le novità servono a rispondere, non sono il punto.

Anticipo la conclusione, così se hai fretta hai già finito: per la maggior parte dei siti questa è una release tranquilla, ma non è una release banale. Contiene un cambiamento strutturale — l’editor dei post ora è sempre dentro un iframe — che è il primo candidato a rompere qualcosa, e sposta l’elaborazione delle immagini dal server al browser, che è la novità più visibile e la più facile da sottovalutare. Se hai plugin che estendono l’editor, il tempo lo spendi in staging, non nel decidere se aggiornare.

Cosa cambia davvero in WordPress 7.1

La release porta oltre 310 ticket chiusi sul core, di cui più di 100 fra migliorie e nuove funzionalità e oltre 180 correzioni di bug, più circa 600 migliorie e 630 correzioni arrivate da Gutenberg. Sono numeri dell’annuncio ufficiale e del Field Guide, non stime.

Di tutto questo, le cose che cambiano qualcosa nella giornata di chi usa o mantiene un sito sono poche. Sono queste.

Le immagini vengono elaborate dal browser, non dal server

È la novità più grossa, ed è quella che quasi nessuno si aspetta di trovare in una release di WordPress. Quando carichi un’immagine, compressione, ridimensionamento e generazione delle miniature avvengono nel tuo browser prima che il file parta verso il server. Il lavoro lo fa wasm-vips, cioè la libreria libvips compilata in WebAssembly; le sotto-dimensioni vengono poi caricate una per una con un nuovo endpoint REST.

Le conseguenze pratiche sono tre, e sono tutte buone:

• L’immagine da 40 MB smette di essere un problema. Il classico errore di memoria PHP durante l’upload sparisce, perché l’elaborazione non usa più la memoria del server.
• I file sono più piccoli. libvips comprime meglio di GD e Imagick: i JPEG generati calano di circa il 15%. Sono byte che i tuoi visitatori non scaricano più.
• I formati moderni non dipendono più dall’hosting. AVIF e HEIC vengono decodificati nel browser anche su server che non li supportano. Le foto scattate con l’iPhone si caricano e basta, e l’originale HEIC resta accanto al file convertito.

C’è un «ma», ed è importante: funziona solo su Chrome ed Edge dalla versione 137 in poi. Su Firefox e Safari WordPress ricade automaticamente sull’elaborazione lato server, senza differenze visibili per chi carica. Non è un guasto: è il comportamento previsto. Significa però che lo stesso sito produce immagini leggermente diverse a seconda del browser di chi le carica, e se in redazione siete in più persone è una cosa da sapere.

Il fallback scatta anche quando il dispositivo non ce la fa: serve più di 2 GB di memoria, almeno 2 core, e una connessione che non sia dichiarata lenta o in modalità risparmio dati. Il modulo che fa il lavoro pesa circa 13 MB da scaricare la prima volta.

L’editor dei post è sempre dentro un iframe

Da 7.1 l’editor dei post è sempre iframed, qualunque sia il tema, qualunque sia la versione delle API dei blocchi registrati, e anche sui siti che registrano meta box vecchio stile. In WordPress 7.0 il comportamento era condizionale: l’iframe si attivava solo se tutti i blocchi in gioco usavano l’API v3. Adesso quella condizione non c’è più.

Per chi scrive è un miglioramento silenzioso: gli stili del pannello di amministrazione non interferiscono più con il contenuto, quindi quello che vedi nell’editor somiglia di più a quello che vedrà il visitatore. Per chi sviluppa è la modifica più impegnativa della release, e la tratto più avanti nella sezione su cosa può rompersi.

Le note diventano conversazioni

Le note nell’editor, introdotte con WordPress 6.9 per la collaborazione asincrona, in 7.1 crescono parecchio: supportano testo formattato (grassetto, corsivo, codice), link e menzioni con la chiocciola. Soprattutto, si possono ancorare a una porzione di testo invece che a un blocco intero, e più conversazioni possono convivere sullo stesso blocco.

Se il tuo flusso editoriale prevede una revisione fatta da qualcun altro, questa è la novità che ti farà risparmiare più tempo — a patto che chi revisiona abbia un account sul sito. Attenzione a non confonderla con la collaborazione in tempo reale, quella con più cursori sullo stesso documento: non è in 7.1, è stata rinviata di nuovo.

Stili responsivi senza scrivere CSS

Si possono applicare stili diversi a seconda della dimensione dello schermo direttamente nell’editor, con anteprima alle varie larghezze, senza CSS personalizzato. È la funzionalità che l’annuncio chiama Apply Responsive Styles, e per chi costruisce pagine è la novità più utile della release.

Sul lato tema c’è il pezzo che mancava: i temi a blocchi possono definire i propri breakpoint per mobile e tablet in theme.json, invece di subire quelli del core. Sempre da theme.json si possono ora dichiarare gli stili degli stati — hover, focus, focus-visible, active — e i blocchi Pulsante possono avere stili distinti per ciascuno.

Se ti stai chiedendo se valga la pena rifare il tema per questo: no, non da solo. Ma se un tema lo stai scrivendo adesso, sono due cose che cambiano come lo imposti.

Due blocchi nuovi: Tab e Playlist

Tab organizza il contenuto in pannelli a schede invece di mostrare tutto insieme. Playlist mette insieme più tracce audio, con forma d’onda opzionale. Entrambi arrivano con il supporto agli screen reader già dentro, il che è una differenza sostanziale rispetto alle decine di plugin che fanno la stessa cosa.

Una nota che vale per il blocco Tab e che non riguarda WordPress: il contenuto nascosto dentro una scheda resta nel codice della pagina, quindi è indicizzabile, ma è contenuto che il lettore non vede al primo colpo. Usarlo per nascondere metà articolo è un modo elegante di peggiorare una pagina. Va bene per specifiche tecniche, varianti, alternative: non per il testo principale.

Il resto, in breve

• La barra di amministrazione resta visibile in tutti gli editor. Piccola cosa, ma toglie l’effetto «sono finito in un posto da cui non so uscire» che il Site Editor dava a chi lo apriva di rado.
• Un ritaglio delle immagini che funziona. Una finestra unica con ritaglio libero e per proporzioni, capovolgimento orizzontale e verticale, rotazione precisa e modifica dei metadati.
• La libreria media scorre all’infinito per impostazione predefinita, e gli upload hanno indicatore di avanzamento e ritentativo automatico.
• Le GIF animate possono essere convertite in video in fase di caricamento. È opzionale, e su un sito che pubblica GIF è il singolo intervento che pesa di più sulle prestazioni.
• Una API pubblica per le icone SVG — wp_register_icon_collection(), wp_register_icon(), wp_get_icon() — con cui plugin e temi possono aggiungere le proprie collezioni a quella del core.
• Due funzioni nuove per l’accessibilità, wp_get_tooltip() e wp_get_toggletip(), che danno finalmente al core un modo standard di esporre nomi accessibili. Insieme a queste, etichette più chiare nelle tabelle di elenco dei post e navigazione più prevedibile.

Chi se ne accorge e chi no

Questa è la parte che gli articoli sulle release di solito saltano, ed è quella che decide se l’aggiornamento ti riguarda oggi o fra tre mesi.

Vale anche la pena sapere cosa non è entrato, perché se stavi aspettando una di queste cose la 7.1 non è la release che ti serve: la collaborazione in tempo reale è stata rinviata, il blocco Classico non ha ricevuto i cambiamenti previsti, e l’aggiornamento a React 19 è slittato. La prossima major è già in preparazione — sul blog degli sviluppatori del core si discute per esempio di una API per la gestione dei segreti — ed è pianificata per il 10 dicembre 2026.

Cosa può rompersi

Quattro cose, in ordine di probabilità. Nessuna riguarda il contenuto del sito: riguardano tutte codice di terze parti che si appoggiava a un comportamento che è cambiato.

1. L’editor iframed e i plugin che toccano il canvas

È il rischio numero uno, e il motivo è tecnicamente semplice: l’iframe ha un proprio document e un proprio window, separati da quelli della pagina di amministrazione. Qualunque JavaScript che faccia una cosa del genere, dentro l’editor, adesso non trova niente:

// Non funziona più: cerca nel documento sbagliato
const blocchi = document.querySelectorAll( '.wp-block-paragraph' );
document.addEventListener( 'click', gestisciClick );

Il codice non va in errore: semplicemente non trova gli elementi, perché sono in un altro documento. È il tipo di guasto più insidioso, perché non compare nella console e si manifesta come «quel pulsante del plugin non fa più niente».

La correzione, per chi sviluppa, è ricavare il documento giusto da un elemento che sta dentro l’iframe, usando ownerDocument e defaultView invece delle variabili globali, e agganciare gli ascoltatori di eventi con useRefEffect, che li ripulisce da solo. La stessa attenzione vale per il CSS iniettato a mano nel canvas.

Se invece il sito è tuo e il plugin è di qualcun altro, la domanda pratica è una sola: quel plugin ha rilasciato un aggiornamento dopo il 19 agosto 2026? Se sì, installalo prima di aggiornare il core. Se no, è esattamente il caso in cui lo staging non è facoltativo. Non risulta un modo previsto per tornare al comportamento precedente: l’iframe non si disattiva.

2. L’elaborazione immagini nel browser e gli hook che non scattano più

Quando il lavoro sulle immagini si sposta nel browser, il codice PHP che si agganciava a quel lavoro non viene più eseguito. Tre hook in particolare non scattano più sul percorso lato client:

• wp_image_editors
• image_memory_limit
• image_make_intermediate_size

Chi ne risente: i plugin di ottimizzazione e conversione delle immagini, le filigrane applicate in fase di caricamento, e qualunque personalizzazione che rigenerava le miniature a modo proprio. Restano invece attivi gli hook sulla qualità — jpeg_quality, wp_editor_set_quality, image_editor_output_format, big_image_size_threshold — quindi le impostazioni di compressione continuano a valere.

Cambia anche wp_generate_attachment_metadata, che ora scatta due volte: una durante il caricamento, con contesto create, e una dopo la finalizzazione, con contesto update. Il codice che assumeva una sola esecuzione va rivisto.

Se qualcosa non torna, si disattiva con una riga in un plugin funzionale:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Un’ultima trappola che vale la pena conoscere perché è difficile da diagnosticare: se il sito ha una Content Security Policy restrittiva, il worker non parte a meno che la policy non consenta worker-src 'self' blob:. Il sintomo è che l’elaborazione nel browser semplicemente non avviene mai, su tutti i browser, e non è ovvio il perché.

3. Il CSS dei blocchi caricato solo quando serve

Il CSS di un blocco viene ora emesso solo se quel blocco è effettivamente presente nella pagina. Per il 99% dei siti è un guadagno netto: meno CSS inutile, pagine più leggere.

Il caso che si rompe è specifico ma reale: le pagine che iniettano contenuto proveniente da altrove — richieste asincrone, contenuti caricati dopo, blocchi resi fuori dal ciclo principale. Se quel contenuto contiene un blocco che nella pagina non c’era, arriva senza i suoi stili e si vede. Il sintomo è un elemento che appare senza formattazione dopo un’interazione, mentre a pagina appena caricata era a posto.

4. jQuery UI aggiornato, e gli stili degli stati

WordPress 7.1 include jQuery UI 1.14.2. I plugin più datati che si appoggiano al comportamento o all’aspetto di jQuery UI vanno provati: è il tipo di aggiornamento che di solito non rompe niente e ogni tanto sposta un calendario di due pixel o cambia la resa di una finestra modale.

Insieme, una correzione che può cambiare l’aspetto di un tema: gli stili degli pseudo-stati non vengono più applicati anche allo stato predefinito del blocco. È il comportamento corretto, ma se un tema si era adattato al comportamento precedente — per esempio dichiarando il colore solo su hover e contando sul fatto che valesse sempre — il risultato cambia.

Come aggiornare senza sorprese

La procedura non la riscrivo qui, perché esiste già ed è completa: backup verificato, controllo di compatibilità di plugin e temi, ambiente di staging, controlli dopo. È tutta nella guida all’aggiornamento di WordPress, e vale per questa release come per tutte le altre.

Quello che aggiungo sono le tre cose specifiche della 7.1, da fare in staging e in quest’ordine, perché sono esattamente i punti che questa release tocca:

1. Apri l’editor su un articolo vero, di quelli complicati, con i campi personalizzati e le meta box che usi davvero. Non su un articolo di prova vuoto: l’iframe forzato si manifesta proprio dove ci sono estensioni di terze parti. Clicca i pulsanti che i plugin aggiungono e controlla che facciano ancora qualcosa.
2. Carica un’immagine grande, sopra i 5 MB, da Chrome o Edge. Verifica che le miniature vengano generate tutte e che l’immagine appaia correttamente nell’articolo. Se usi un plugin di ottimizzazione immagini, questo è il momento in cui scopri se lavora ancora.
3. Guarda il sito pubblico, non solo il pannello: una pagina con il tuo tema, gli stati dei pulsanti, e una pagina che carica contenuto dopo l’apertura, se ne hai.

Se il sito non ha uno staging, la 7.1 è un buon motivo per crearlo, e nel frattempo l’alternativa ragionevole è aspettare qualche settimana: i plugin che devono adeguarsi all’iframe lo stanno facendo adesso. Aspettare la 7.1.1 non è pigrizia, è una scelta difendibile — a patto che sia una scelta, cioè con una data segnata da qualche parte. Se gli aggiornamenti sul tuo sito sono già dentro una routine con backup e controlli periodici, questa decisione l’hai già presa: la checklist di manutenzione WordPress mette la lettura dei changelog fra i controlli trimestrali proprio per questo.

Le minori invece non aspettano

Tutto quello che hai letto finora vale per le major. Con le minori il ragionamento è opposto, e conviene averlo chiaro perché la differenza costa.

Poche settimane prima della 7.1, il 12 agosto 2026, è uscita la 7.0.4: una release di sicurezza che correggeva una vulnerabilità di esecuzione di codice da remoto tramite caricamento di file, sui siti che usano Imagick e Ghostscript. Sei giorni prima era uscita la 7.0.3. Questo è il ritmo normale, ed è il motivo per cui gli aggiornamenti minori automatici vanno lasciati attivi: quando una vulnerabilità diventa pubblica, la finestra fra l’annuncio e lo sfruttamento di massa si misura in ore, non in settimane.

La regola pratica sta in una riga: le minori si installano da sole e va bene così, le major si programmano. Se non sai in che stato sono gli automatismi sul tuo sito, è il controllo numero 2 della checklist di sicurezza WordPress, e si verifica in un minuto.

Se sei ancora su WordPress 6.x

Qui cambia il discorso, e vale la pena essere espliciti: se il tuo sito è fermo alla serie 6, il salto che conta non è la 7.1. È la 7.0.

WordPress 7.0 «Armstrong», uscita il 20 maggio 2026, è la release che ha cambiato le fondamenta: ha portato nel core un client per dialogare con i modelli di intelligenza artificiale insieme alla Abilities API, ha rifatto l’aspetto della bacheca portandoci dentro la palette dei comandi (⌘K), e ha aggiunto i controlli di visibilità per dispositivo e il CSS a livello di singolo blocco. Il dettaglio di quel passaggio, insieme a tutte le release precedenti, è nella tabella delle versioni di WordPress. La 7.1, al confronto, è una release di rifinitura e completamento — completa il passaggio all’iframe cominciato lì, estende le note di 6.9, rende pubblica l’API delle icone.

La conseguenza operativa è che saltare da 6.x a 7.1 non è un aggiornamento, è un progetto, e va trattato come tale: staging obbligatorio, inventario dei plugin fatto prima, tempo previsto per sistemare quello che non passa. Non c’è bisogno di passare per le versioni intermedie — WordPress aggiorna direttamente all’ultima — ma i cambiamenti si sommano tutti nello stesso momento, e i plugin fermi da anni sono il punto in cui il progetto si complica.

Prima di cominciare, un controllo che si fa in trenta secondi e che ogni tanto cambia il piano: la versione di PHP. Da Strumenti > Salute del sito > Info > Server. 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. Il numero cambia: l’elenco aggiornato lo trovi qui. Se sei su una versione vecchia, l’aggiornamento di PHP viene prima e si fa dal pannello dell’hosting: nella guida all’installazione e alla configurazione ho descritto come è fatto lo stack sotto WordPress.

Da dove viene quello che hai letto

Ogni fatto in questa pagina viene da una fonte primaria: il post di annuncio ufficiale di WordPress 7.1, il Field Guide della release con le note per sviluppatori sull’editor iframed e sull’elaborazione delle immagini lato browser, e la pagina di documentazione della versione 7.1. I requisiti di sistema vengono dalla pagina ufficiale dei requisiti.

Lo scrivo perché sulle release di WordPress circola parecchio materiale che descrive funzionalità che non esistono, ed è impossibile distinguerlo a colpo d’occhio: è scritto bene, ha i numeri di versione giusti e la struttura giusta. L’unica difesa è controllare i nomi delle funzionalità 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: 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.