WordPress 7.1, 19 agosto: cosa si rompe nel pannello

Cosa succede il 19 agosto 2026

La data è sulla roadmap ufficiale di WordPress.org: 7.1 esce il 19 agosto 2026. La release candidate è già in giro dal 5 agosto, insieme alla Field Guide che elenca per gli sviluppatori tutto quello che cambia sotto il cofano.

Dentro c'è una riga che in Italia non ha ancora raccontato quasi nessuno. Si intitola Post list tables row headers changed, è stata pubblicata il 3 agosto sul blog degli sviluppatori del core, e descrive uno scambio di posto fra due celle di una tabella.

Detta così sembra una nota per gente che passa la giornata dentro l'ispettore del browser. In parte lo è. Ma quella tabella è l'elenco degli articoli, delle pagine, dei prodotti — la schermata dove il tuo cliente, o tu, passate il tempo quando lavorate sul sito. E i plugin che ci lavorano sopra sono decine di milioni di installazioni.

Cos'è cambiato nelle tabelle del pannello

La definizione corta, quella che serve se devi spiegarla a qualcun altro in una riunione.

In WordPress 7.1 la casella di spunta a sinistra di ogni riga smette di essere l'intestazione di quella riga e diventa una cella normale; l'intestazione diventa la colonna del titolo, che riceve anche il nome dell'articolo come etichetta per i lettori di schermo.

Il motivo è di accessibilità, ed è ragionevole. Oggi un lettore di schermo che annuncia la riga legge "casella di spunta". Dal 19 agosto legge il titolo dell'articolo. Chi naviga il pannello senza vedere lo schermo sa finalmente di quale articolo sta parlando la riga.

Il blog degli sviluppatori lo scrive così, testuale:

"This change significantly improves accessibility for post list tables by ensuring that the naming used for screen readers to identify the current row refers consistently to the name of the relevant post."

Il ticket che lo chiedeva porta il numero 32892. Non siamo riusciti ad aprirlo: il tracker di WordPress risponde 403 alle richieste automatiche e chiede di risolvere un controllo nel browser. Il numero lo citiamo perché lo cita la Field Guide, non perché l'abbiamo letto.

Il test: 7.1-RC2 con dodici plugin veri

Le note di rilascio dicono cosa cambia nel codice. Non dicono cosa succede a un sito con dei plugin sopra. Quella parte l'abbiamo misurata stamattina, e il metodo è ripetibile.

Abbiamo montato una installazione pulita in un contenitore isolato, ci abbiamo messo dodici plugin fra i più diffusi tutti attivi insieme, abbiamo fotografato l'HTML di sette schermate del pannello, aggiornato il core alla release candidate e rifotografato le stesse sette schermate con lo stesso utente e la stessa sessione.

Ecco cosa produce WordPress 7.0.3 per la prima riga dell'elenco articoli:

<th scope="row" class="check-column"> … casella di spunta
<td class="title column-title has-row-actions column-primary page-title"> … titolo

E questo è lo stesso identico sito, dopo l'aggiornamento a 7.1-RC2:

<td class="check-column"> … casella di spunta
<th scope="row" class="title column-title has-row-actions column-primary page-title"
    aria-label="Articolo di prova 3"> … titolo

Le classi restano le stesse. Cambia il tag che le porta, e compare l'etichetta con il titolo dentro. È tutto qui il cambiamento: due lettere in due punti.

La notizia buona, che è anche la più importante: dopo l'aggiornamento non è sparita una sola colonna. Le quattordici colonne dell'elenco articoli — comprese le sei aggiunte da Yoast SEO e quella di All in One SEO — sono ancora tutte lì, con lo stesso contenuto.

Non solo gli articoli: cambiano sette tabelle su sette

Qui il nostro test ha trovato qualcosa che l'annuncio non dice.

Il titolo della nota parla di post list tables, le tabelle degli articoli. Chi l'ha ripresa ha scritto la stessa cosa: cambiano gli elenchi di articoli, pagine e tipi di contenuto personalizzati. Noi abbiamo controllato sette schermate diverse, e sono cambiate tutte e sette.

Il motivo si legge nel codice del core, e spiega perché era prevedibile. La modifica non è dentro la classe che disegna l'elenco degli articoli: è dentro WP_List_Table, la classe base da cui ereditano tutte le tabelle del pannello. La riga che emette la cella è questa, in wp-admin/includes/class-wp-list-table.php:

if ( 'cb' === $column_name ) {
    echo '<td class="check-column">';
    echo $this->column_cb( $item );
    echo '</td>';
}

Chiunque abbia costruito un elenco personalizzato estendendo quella classe — ed è il modo documentato di farlo — eredita il cambiamento senza aver toccato niente. Un punto che consideriamo importante in questo articolo: se hai un plugin su misura con un suo elenco nel pannello, riguarda anche te, anche se la nota parla solo di articoli.

Prima e dopo, in tabella

I tre plugin che nominano le celle, e l'unico che si rompe

La schermata dell'elenco articoli, con i nostri dodici plugin attivi, carica 195 fra fogli di stile e file JavaScript. Li abbiamo scaricati tutti e cercati uno per uno, con il nome esatto delle due celle che cambiano.

Tre plugin le nominano. Solo uno si rompe. La differenza fra i tre è la parte utile di questa pagina, perché è la stessa differenza che troverai nel tuo codice.

Admin Columns: la selezione delle righe smette di funzionare

Nel file assets/js/table.js c'è la funzione che raccoglie le righe spuntate. Il selettore è questo, letterale:

querySelectorAll("tbody th.check-column input[type=checkbox]:checked")

Su WordPress 7.0.3 quel selettore trova quattro caselle nel nostro elenco di prova. Su 7.1-RC2 ne trova zero. Non è una previsione: è il conteggio fatto sulle due pagine salvate, la stessa pagina prima e dopo.

Quella funzione alimenta le tre che stanno sotto: quante righe hai selezionato, quali celle appartengono alle righe selezionate, se hai selezionato tutto. Con zero al posto di quattro, la modifica in blocco continua a disegnarsi ma non trova niente su cui lavorare. La versione pubblica di Admin Columns è la 7.0.19, aggiornata il 29 maggio 2026: due mesi prima che questa modifica venisse annunciata.

All in One SEO: sei regole di stile, ma su tabelle sue

Due fogli di stile di All in One SEO contengono sei regole scritte su th.check-column. Sembra grave, e invece non lo è: ogni regola è preceduta da .aioseo-wp-table, cioè vale solo dentro le tabelle che il plugin disegna nelle proprie schermate. L'elenco articoli di WordPress non le vede nemmeno. Al massimo, dal 19 agosto, qualche cella nelle schermate di AIOSEO avrà una spaziatura leggermente diversa.

Yoast SEO: un falso positivo, e vale la pena spiegarlo

Il file edit-page.js di Yoast contiene un closest("th"), che a una ricerca automatica sembra esattamente il problema. Letto per intero, cerca la cella che contiene un'icona di aiuto nell'intestazione della tabella — la riga in alto, quella con i nomi delle colonne. Quelle celle sono rimaste th anche in 7.1. Yoast non è toccato.

Il core, per parte sua, ha fatto i compiti. Il foglio di stile list-tables.css di 7.1-RC2 dichiara le larghezze su entrambe le forme, la vecchia e la nuova, nella stessa regola. Chi aggiorna non vede nessuno spostamento nel pannello standard.

Cosa ti serve per fare la stessa verifica

• Una copia del sito che non sia quello vero. Una copia di prova, un ambiente locale, un sottodominio chiuso: uno qualsiasi dei tre. Se non ce l'hai, questa è la settimana giusta per accorgertene — su un hosting WordPress gestito la copia di prova è già lì e si crea con un clic.
• L'elenco dei plugin che toccano il pannello. Quelli che aggiungono colonne agli elenchi, che riordinano le righe, che fanno modifica rapida o modifica in blocco. Gli altri quasi certamente non c'entrano.
• Il tuo tema di amministrazione o i tuoi CSS su misura, se ne hai. Sono il posto più probabile in cui trovare una regola scritta a mano su th.check-column.
• Dieci minuti. Non serve di più, e la parte lunga è aprire la copia di prova.

Come verificare il tuo sito in dieci minuti

Due strade, a seconda di quanto sei a tuo agio con il terminale. Servono entrambe allo stesso scopo: sapere se nel tuo codice esistono le due righe che cambiano significato.

Senza terminale. Nel pannello, apri l'elenco degli articoli, fai clic destro su una casella di spunta e scegli "Ispeziona". Se il riquadro evidenziato è un <th>, sei ancora su 7.0. Poi guarda i plugin attivi: quanti di loro aggiungono colonne a questo elenco? Quelli sono i candidati, e sono i soli che vale la pena provare su una copia.

Con il terminale, dalla cartella del sito:

grep -rn "th\.check-column" wp-content/plugins wp-content/themes
grep -rn "td\.column-title\|td\.title\b" wp-content/plugins wp-content/themes

Ogni risultato è un candidato. Per capire se è davvero un problema, guarda due cose: il file viene caricato nella schermata degli elenchi, oppure vive in una schermata sua? E la regola è preceduta da una classe del plugin, come nel caso di All in One SEO? Se la risposta alla seconda è sì, puoi passare oltre.

Il blog degli sviluppatori indica anche la correzione, e vale sia per chi scrive plugin sia per chi ha due righe di CSS su misura nel proprio tema di amministrazione:

"Retaining both td and th selectors will support retaining compatibility with versions of WordPress prior to 7.1."

Tradotto in pratica: non sostituire th.check-column con td.check-column. Scrivili tutti e due, separati da una virgola. La regola funziona su entrambe le versioni e non dovrai tornarci.

Cosa non succede il 19 agosto

• Il sito pubblico non cambia. Nessuna pagina, nessun modulo, nessun prezzo, nessuna velocità. La modifica vive solo dentro /wp-admin/.
• Non sparisce nessuna colonna. Nel nostro test, tutte e quattordici le colonne dell'elenco articoli sono rimaste al loro posto con i loro dati.
• Non è una falla di sicurezza. Non c'entra niente con gli aggiornamenti urgenti — quelli hanno un'altra faccia, come la falla di WooCommerce Social Login di questo mese. Questa è una modifica di accessibilità, pianificata e annunciata sedici giorni prima.
• Non riguarda il tuo tema pubblico. A meno che tu non abbia scritto CSS per il pannello dentro il tema, cosa che quasi nessuno fa.
• Non si rompe la modifica rapida di WordPress. Quella del core continua a funzionare: il core ha aggiornato i propri selettori insieme al markup.

Chi dichiara di averlo già provato, otto giorni prima

Ogni plugin nella directory ufficiale dichiara fino a quale versione di WordPress è stato provato. Non dichiara di essere compatibile: dichiara che qualcuno ha guardato. È l'unico segnale pubblico che hai, ed è gratis da leggere.

Questi sono i dodici plugin del nostro test, con i numeri presi dall'API di WordPress.org stamattina, 11 agosto 2026.

Sommate, sono oltre 66 milioni di installazioni attive — le cifre di WordPress.org sono arrotondate per difetto, quindi il numero vero è più alto. Di dodici plugin, uno solo dichiara di averlo già provato su 7.1: Wordfence, aggiornato il 10 agosto.

Questo numero va letto per quello che è, altrimenti diventa allarmismo. Otto giorni prima di una release, "provato fino a 7.0.3" è la normalità: molti autori aggiornano la dichiarazione il giorno stesso dell'uscita, o nei giorni successivi. Non è la prova che undici plugin si romperanno. È la misura di quante case hanno già acceso la luce.

Glossario, per chi non scrive codice

Tre soglie: dove ti trovi

Alla fine di una pagina come questa serve una posizione, non un riassunto. Trova la tua.

• Hai solo plugin dalla directory ufficiale e nessun codice su misura nel pannello. Sei al primo gradino: aggiorna quando vuoi, guarda l'elenco articoli una volta dopo l'aggiornamento e passa oltre.
• Hai plugin che aggiungono colonne, riordinano righe o fanno modifica in blocco. Sei al secondo: prova su una copia prima del 19, e se l'autore non ha ancora dichiarato 7.1, aspetta una settimana. Non ti costa niente aspettare.
• Hai un plugin su misura, un tema di amministrazione o CSS scritti da qualcuno per te. Sei al terzo: fai le due ricerche del paragrafo precedente oggi. Se trovano qualcosa, la correzione è una virgola e due parole, e chi te l'ha scritto la applica in mezz'ora.

Se la copia di prova non ce l'hai — ed è il caso più comune fra i siti piccoli — quello è il problema vero, e non nasce con questo aggiornamento. Un hosting WordPress gestito con ambiente di prova esiste esattamente perché un mercoledì di agosto tu possa aggiornare senza chiederti cosa succede. Noi lo montiamo per i siti che seguiamo, e non è una cosa che si compra: è una cosa che si prepara una volta e poi resta lì.

Domande che nessuno ci ha fatto

Nessuno ci ha ancora scritto su WordPress 7.1: la release candidate è uscita la settimana scorsa e la modifica è sepolta in una nota tecnica. Queste sono le domande che ci faremmo leggendo l'annuncio a freddo, più quelle che tornano ogni volta che un aggiornamento importante si avvicina.

Ultimo aggiornamento: 11 agosto 2026. WordPress 7.1 è previsto per il 19 agosto 2026 secondo la roadmap ufficiale di WordPress.org; la release candidate 2 è la versione più recente pubblicata sul canale beta. Il test descritto in questa pagina è stato eseguito l'11 agosto 2026 su WordPress 7.0.3 e 7.1-RC2, con PHP 8.3 e i dodici plugin elencati nella tabella. Ripetiamo la stessa prova sulla versione finale il 19 agosto e aggiorniamo questa pagina con il risultato, compresa la colonna "provato fino a", che il giorno del rilascio cambia per quasi tutti i plugin.