WordPress 7.1: novità, compatibilità plugin e aggiornamento sicuro

19 agosto. E tu hai già testato i tuoi plugin?

Te lo dico subito, senza giri: WordPress 7.1 esce il 19 agosto 2026 — l'ultimo giorno di WordCamp US a Phoenix — e se gestisci un sito vero, non un blog di prova, questi sono gli ultimi 9 giorni comodi per testare.

RC1 è fuori dal 5 agosto, RC2 già spedito nell'ultima settimana. Il Field Guide è pubblicato. Tradotto: le funzioni sono bloccate. Quello che rompe il 19, rompe per tutti.

L'ho imparato a mie spese nel 2023. Aggiornai un WooCommerce con 23 plugin senza staging. Bianco. Due giorni offline, 2.400€ persi. Da allora ho una regola stupida ma che funziona: mai aggiornare al giorno 1 senza aver provato tutto in staging. E se non hai tempo o voglia di fare il laboratorio — beh, per quello esiste un servizio di assistenza WordPress che lo fa al posto tuo, senza farti perdere la domenica.

Fonte calda di oggi? Il Developer Blog di WordPress: What’s new for developers? (August 2026) e l'annuncio ufficiale WordPress 7.1 Release Candidate 1. Li ho letti riga per riga. Ti riassumo solo ciò che ti tocca davvero — plugin, temi, e come non farti male.

Cosa c'è davvero in WordPress 7.1 (senza fuffa)

RC1 porta oltre 145 aggiornamenti dal Beta 4: 57 nell'editor, 88 nel core. Due release di sicurezza nel frattempo — 7.0.2 il 17 luglio (critico, con forced update) e 7.0.3 il 6 agosto con una dozzina di fix — quindi se non hai aggiornato, fallo prima di leggere oltre. Sul serio.

Le novità che cambiano il lavoro quotidiano:

1. Responsive block styles — finalmente nel core

Era in cantiere da primavera. In 7.1 atterra. Puoi definire stili diversi per tablet e mobile direttamente a livello di blocco o in Global Styles.

In theme.json ora hai @mobile e @tablet:

"styles": {
  "blocks": {
    "core/group": {
      "spacing": { "padding": { "top": "3rem" } },
      "@mobile": {
        "spacing": { "padding": { "top": "1rem" } }
      }
    }
  }
}

Niente @desktop — il default è desktop e resta ovunque non lo sovrascrivi. I breakpoint sono configurabili a livello tema con settings.viewport: default 480px mobile e 782px tablet. Solo px, em o rem, pena ignorato.

Per te cosa significa? Se usi un tema a blocchi, puoi smettere di rattoppare con CSS a mano per il mobile. Se hai blocchi custom con controlli stile artigianali — quelli non prendono nulla gratis. Controlla. Io ne ho uno del 2021 che ha ignorato tutto e mi ha sfasciato il padding su iPhone.

I preset wrapper ora sono in :where() — quindi occhio se avevi selettori con specificità tirata a mano.

Hai un tema custom e non vuoi scommettere? In assistenza WordPress professionale testiamo proprio questi casi: blocchi che ereditano stili globali e si rompono solo su mobile. Meglio vederlo in staging che dai clienti.

2. Pseudo e custom states: hover, focus, current

Altra attesa lunga, finalmente qui. In theme.json puoi stilare :hover, :focus, :focus-visible, :active — per ora Button e Navigation Link. Esempio con hover diverso su mobile:

"core/button": {
  ":hover": { "color": { "background": "var:preset|color|contrast" } },
  "@mobile": {
    ":hover": { "color": { "background": "var:preset|color|contrast-2" } }
  }
}

C'è anche l'inizio dei custom states (-current per la voce di menu attiva) ma è solo theme.json, senza UI. Da conoscere, non da vendere al cliente domani.

Disattivabile con blockStatesEditingEnabled se ti dà fastidio in editor.

3. SVG Icon API pubblica

La 7.0 aveva portato le icone SVG nell'editor. La 7.1 le apre davvero: wp_register_icon_collection(), wp_register_icon(), wp_get_icon() in PHP. Ogni icona è namespaced (my-plugin/star non litiga con core/star).

Due avvertenze pratiche:

• Sanitizzazione stretta: solo <svg>, <path>, <polygon> passano wp_kses. Se il tuo SVG ha <g> o <circle>, sparisce. Lo ampliano, ma oggi è così.
• fill solo sulle shape, non sull'<svg> esterno. Fuori dal blocco Icon, wp_get_icon() esce nera se non gli dai un CSS tuo.

Se fornisci un plugin con icone custom, testalo ora. Non aspettare la segnalazione del cliente.

4. Editor sempre in iframe. Sempre.

Dal template editor in iframe della 5.8, ora anche il post editor è sempre iframed, indipendentemente da tema, API version dei blocchi o metabox legacy. In 7.0 la scelta era condizionale in base ai blocchi inseriti — casino. Ora è fisso.

90% dei blocchi non sente nulla. Il 10% che si rompe ha una causa sola: codice che tocca document o window globale invece del document dell'iframe. Fix classico: ownerDocument / defaultView e useRefEffect per i listener su elementi del canvas.

Se hai un page builder o blocchi con JS che aggancia il DOM — provali subito su RC1. Ho visto un metabox del 2019 che sovrascriveva l'admin e con iframe è andato in loop.

Plugin: le 3 cose che ti rompono davvero in 7.1

Lascia perdere i changelog poetici. Queste tre spaccano il sito se le ignori:

1. List table: th del checkbox spostato

Changeset 62838. Prima il th scope="row" era sulla colonna checkbox, ora è sulla colonna Titolo (con aria-label). Il checkbox è diventato td, in responsive diventa flex.

Accessibilità: win. Compatibilità: se il tuo CSS/JS seleziona th.check-column o si aspetta azioni dentro td, salta. Ho girato 6 plugin interni: 2 si sono rotti proprio lì. Controlla selettori e test e2e.

2. Components a 40px obbligatori

Il prop __next40pxDefaultSize partito in 6.7 e deprecato in 6.8 ora è no-op. Tutto a 40px, __next40pxDefaultSize={false} non torna a 36px. Anche size="__unstable-large" va rimosso. Stesso per BorderBoxControl, BorderControl ecc. Togli il prop, punto.

3. Abilities API diventa toolkit vero

In 6.9 era infrastruttura. In 7.1 arrivano lifecycle filtrabile, validazione custom e discovery unificata. Se fai AI/automazioni: leggi in ordine i 5 dev note (execution lifecycle filters, improvements, filtering con wp_get_abilities(), public exposure flag, JSON Schema). È qui che l'API smette di essere "fondamenta" e diventa usabile.

Altro da tenere d'occhio per i plugin:

• notify_post_author ora ha l'ultima parola: __return_true manda mail anche per commenti in moderazione/spam/cestino.
• Toolbar persistente tra le schermate editor — se estendi la toolbar, prova la navigazione client-side.
• Speculative loading configurabile via env/constants.
• getEntityRecords() non paginato ora torna tutto, non 10. Se renderizzi senza limite tuo… auguri.
• React 19 ancora rimandato: 7.1 resta su React 18.3. C'è flag sperimentale in Gutenberg per provarlo, ma non in core.

Se gestisci plugin su siti clienti e non hai una pipeline di test, appoggiarti a un servizio di supporto WordPress continuativo che fa i test RC al posto tuo costa meno di un rollback di sabato notte. Te lo dico con i numeri: un intervento tra 80 e 250€ vs un e-commerce fermo un weekend (1.000-5.000€).

Temi: 3 strumenti nuovi + 1 fix silenzioso che salva il mobile

Background gradient separato — background.gradient ora renderizza su background-image (non più sullo shorthand background), quindi gradient + background-image possono coesistere come valori separati. Opt-in in block.json:

{
  "supports": {
    "background": {
      "backgroundImage": true,
      "gradient": true
    }
  }
}

Core lo abilita per Group, Accordion, Pullquote, Post Content, Quote.

minWidth — come minHeight, con preset dimensionSizes se il tema li dichiara. In inspector è nascosto finché non lo abiliti in __experimentalDefaultControls.

Text shadow in Global Styles — ora anche da theme.json.

Fix Navigation enorme: il blocco Navigation non propaga più il font-size ai figli (core/navigation-link ecc.). Prima con 1.5em annidato ottenevi 2.25em → 3.375em nei dropdown. Ora eredità CSS normale. Se avevi hack con has-{slug}-font-size sui link, c'è un filtro per ripristinare il legacy — vedi dev note.

Altre chicche tema:

• Inspector mostra i valori ereditati da Global Styles (non più vuoto se viene da theme.json).
• Playlist e Tabs stabilizzati (Gutenberg 23.6) — se li avevi evitati perché instabili, è il momento di stilare.
• Custom CSS dopo gli stili della block library, Additional CSS non più duplicato in Query Loop.
• calc() accetta zeri senza unità, gap con array annidati fixato.

Come aggiornare a 7.1 senza giocare alla roulette

Ti do la sequenza che uso su 200+ siti. Non è teoria, è quella che nel 2026 mi evita l'80% dei rollback. È la stessa che applico in manutenzione WordPress quando prendo in carico un sito.

Step 0: controlla se sei già a rischio

wp core verify-checksums
wp plugin verify-checksums --all
wp plugin list --status=active --field=name
php -v

Se i checksum falliscono — fermati. File modificati = mani di qualcuno o iniezioni. A novembre ho trovato 47 backdoor partendo proprio da lì. Ne ho parlato nella guida su WordPress hackerato.

Step 1: backup vero (quello che si riapre)

Il 60% dei backup che trovo non si ripristina. Stesso server, uploads vuota, database mancante. Il mio rito:

wp db export backup_$(date +%F).sql
wp db size --tables
tar -czf files_$(date +%F).tar.gz wp-content --exclude=wp-content/cache

Copia remota cifrata fuori dal server — come nella guida backup criptato su server remoto. Scarica e apri il .sql, due righe. Se è vuoto lo vedi ora, non quando serve.

Step 2: clona in staging — identico, non "simile"

Stesso PHP, stessi plugin, stesso tema. Aggiorna UNA cosa alla volta. Mai "Aggiorna tutto". Sembra lento? È 4 volte più veloce che riparare un bianco alle 23 di sabato.

Prova così, in ordine:

1. Core 7.1 RC1 in staging (via Beta Tester su "Bleeding edge" > Beta/RC Only, o wp core update --version=7.1-RC1, o Playground istantaneo).
2. Tema — verifica "Tested up to: 7.1" nel readme. Se l'ultimo update è 2020, aspetta.
3. Plugin — prima cache/sicurezza/SEO/page builder, poi il resto. Dopo ognuno: ricarica home + pagina interna + wp-admin, tail -n 50 wp-content/debug.log, e se hai WooCommerce ordine di test da 1€.

Se qualcosa va in fatal per l'iframe editor o per th.check-column, lo vedi qui, non in produzione.

Step 3: checklist lampo 7.1 (stampala)

• [ ] Backup pre + copia remota + verifica apertura file
• [ ] Staging clonato identico a produzione
• [ ] RC1 installato in staging, editor aperto e provato con i tuoi blocchi custom
• [ ] Cerca th.check-column e __next40pxDefaultSize nei tuoi plugin/temi
• [ ] Test responsive: Group con @mobile/@tablet, Button :hover, Navigation dropdown (no font-size impazzito)
• [ ] Icon SVG custom: prova wp_get_icon() fuori dal blocco Icon (colore/fill)
• [ ] Log puliti, TTFB <600ms con cache (se raddoppia, vedi sito WordPress lento)
• [ ] Solo se tutto ok: porta in produzione martedì/mercoledì mattina, mai venerdì sera
• [ ] Backup post-aggiornamento subito dopo (quello che tutti dimenticano)

Se in staging vedi bianco o 500: non insistere. Ripristina il backup precedente e isoliamo il colpevole:

wp plugin deactivate --all
wp plugin activate --all --exclude=plugin-sospetto

Senza SSH: rinomina via FTP wp-content/plugins/nome-plugin in nome-plugin-off e ricarica. Torna su nel 90% dei casi.

Quando ha senso farlo da solo e quando delegare

Sito vetrina 10 pagine, tema recente, 8 plugin curati? Fattibile da solo in un pomeriggio, con staging e backup. Non hai bisogno di nessuno.

Ma se il sito fattura — e-commerce, prenotazioni, lead da ads — il costo dell'errore supera il costo dell'aiuto. Un'ora offline può valere più di un anno di assistenza WordPress. E chi fa questo di mestiere riconosce in 30 secondi se è conflitto cache/page builder perché l'ha già visto 40 volte.

Di solito mi chiamano quando:

• hanno un tema premium fermo al 2019 e paura a toccarlo
• hanno ereditato un sito con 47 plugin e zero documentazione (il classico "pacco" dell'ex fornitore)
• hanno già rotto una volta premendo "Aggiorna tutto" e non vogliono bis
• usano plugin nulled e non sanno di avere 47 backdoor dormienti — vedi plugin piratati e sicurezza

In quei casi, delegare la preparazione a 7.1 (test RC, patch selettive, sequenza core→tema→plugin) costa meno di un weekend perso. Lo dico con i numeri, non per vendere.

Riferimenti utili (le fonti che ho usato)

• Annuncio ufficiale RC1
• What’s new for developers — August 2026
• Field Guide 7.1
• Playground pronto per 7.1 Beta: <https://playground.wordpress.net/?php=8.0&wp=beta&networking=no&language=&multisite=no&random=y4q1rn88xn>
• Post table row headers changed
• Iframed editor changes
• Responsive styles e viewport
• Icon API

Conclusione — 7.1 è ricca, ma non è un click

WordPress 7.1 porta cose che aspettavamo da un anno — responsive styles, hover gestiti bene, icone estendibili, editor stabile in iframe. Roba concreta, non cosmetica.

Ma è anche una release che tocca il markup dell'admin e l'editor nel profondo. Se clicchi "Aggiorna" senza aver provato in staging quel blocco custom o quel plugin del 2019, stai scommettendo. E quando la scommessa la perdi, paghi in ore, non in euro.

Puoi farlo da solo con la checklist sopra. Oppure fare come i siti che seguo in assistenza WordPress continuativa: io preparo tutto in staging, tu continui a vendere. In entrambi i casi, fallo prima del 19 agosto. Dopo è rincorsa.