Il rilascio di WordPress 7.1, previsto per il 19 agosto 2026, arriva a meno di cinque mesi dal rilascio di WordPress 7.0 Armstrong e ha una portata insolita: tocca sia il front-end editoriale che l'infrastruttura server. Per chi gestisce siti in produzione è l'aggiornamento più impegnativo del 2026, sia per la complessità del client-side media processing, sia perché la Abilities API passa da "disponibile come opt-in" a "stabilmente integrata con il Bridge AI".

L'articolo di riferimento, pubblicato da Kinsta all'inizio di agosto, delinea le novità: client-side media processing, nuova persistent admin bar, Identity screen nel Site Editor, Notes features, blocchi nuovi e migliorati, Abilities API matura. Ma l'articolo non entra nel merito di una questione concreta: in che ordine aggiornare, su quali siti l'aggiornamento può essere critico, e cosa verificare nelle prime 72 ore post-update.

Questa guida colma quel vuoto. È una guida operativa per chi ha siti in produzione e deve decidere se e come fare l'aggiornamento a 7.1. Si rivolge a uno sviluppatore senior che ha letto le note di rilascio e vuole un piano d'azione. Non copre le novità in dettaglio (ci sono le note di rilascio ufficiali), ma piuttosto il prima, il durante e il dopo l'aggiornamento. Si completa con le analisi già pubblicate su mrtux.it, tra cui la panoramica sulle novità core di WordPress 6.9 e l'Abilities API, e l'approfondimento sull'Abilities API per casi d'uso non-AI.

Cosa cambia davvero in 7.1

Le novità di WordPress 7.1 si dividono in tre famiglie. La prima famiglia è la client-side media processing: la generazione di thumbnail e la conversione di formato, prima fatta server-side con PHP e GD/Imagick, vengono ora eseguite nel browser dell'utente via WASM. Il supporto però non è universale: solo Chrome 137+ e Edge 137+ per desktop supportano pienamente il Document-Isolation-Policy (DIP) che concede l'accesso al SharedArrayBuffer necessario al WASM. Safari decodifica nativamente HEIC/HEIF in JPG ma non supporta la pipeline WASM. Firefox non supporta né WASM né la decodifica HEIC. In tutti questi casi il core esegue il fallback server-side in modo trasparente.

La seconda famiglia è la Notess feature: la possibilità di lasciare note testuali su un post, su un commento, su una pagina, visibili nel back-office agli utenti con il permesso giusto, con reply, mention e cronologia. È uno strumento di redazione che mira a sostituire la proliferazione di plugin di team collaboration. Notes è opt-in per site admin, non per default.

La terza famiglia riguarda il Site Editor: arriva la persistent admin bar (non più ancorata allo scroll) e una nuova schermata Identity che permette di gestire il logo, lo stile del brand e l'identità del sito in un posto solo. A queste si aggiungono miglioramenti ai blocchi già esistenti e l'integrazione matura della Abilities API con il Bridge AI introdotto con 7.0.

Cosa va verificato PRIMA dell'aggiornamento

La regola d'oro di ogni aggiornamento WordPress è aggiornare prima in staging, poi in produzione. Con WordPress 7.1 questa regola diventa assolutamente obbligatoria, perché la probabilità di plugin incompatibili è più alta del solito: WASM nel browser tocca pipeline che molti plugin di image optimization non hanno ancora testato.

Test del proprio stack plugin

Il primo passo è un audit WP-CLI dei plugin attivi. Serve identificare tutti i plugin che modificano il flusso di upload immagini, perché sono quelli a rischio: plugin di lazy load che intercettano i thumbnail, plugin di compressione server-side (ShortPixel, Imagify, Smush) che girano in wp_handle_upload, plugin di WebP che sostituiscono le varianti generate dal core.

# audit plugin attivi che toccano il flusso immagini
wp plugin list --status=active --allow-root --format=csv \
  | awk -F, '$3 ~ /image|photo|media|optim|compress|webp/i {print $2}'

# nel mio caso di test: shortpixel-image-optimiser, smush, ewww-image-optimizer
# verifico compatibilità annunciata con 7.1
for plugin in shortpixel-image-optimiser smush ewww-image-optimizer; do
  echo "=== $plugin ==="
  wp plugin get "$plugin" --field=description --allow-root
  echo "ultimo changelog entry:"
  wp plugin get "$plugin" --field=version --allow-root
done

Test del flusso immagini in staging

Una volta identificati i plugin a rischio, si replica in staging il flusso immagini: si carica una immagine JPG da 5 MB, si verifica che le varianti (thumbnail, medium, large, 1536x1536, 2048x2048) siano effettivamente generate e che il browser che le riceve sia in grado di visualizzarle. In staging si testa sia con Chrome (dove la pipeline è client-side) che con Safari (dove invece è server-side) per essere sicuri che entrambi i percorsi funzionino.

Test del Bridge AI

Se il sito usa il Bridge AI introdotto con WordPress 7.0, va testato che la Abilities API ora matura di 7.1 risponda correttamente. Lo script di test è banale.

# verifica capabilities del Bridge
wp eval '
if (function_exists("wp_ai_get_bridge")) {
    $bridge = wp_ai_get_bridge();
    if (!is_wp_error($bridge)) {
        $caps = wp_ai_get_connector_capabilities();
        echo "Capabilities registrate: " . count($caps) . "\n";
        foreach ($caps as $cap) {
            echo "  - " . $cap->id . " v" . $cap->version . "\n";
        }
    } else {
        echo "Errore Bridge: " . $bridge->get_error_message() . "\n";
    }
} else {
    echo "Bridge AI non disponibile: richiesto WP >= 7.0\n";
}
' --allow-root

Output atteso dopo l'aggiornamento a 7.1: Capabilities registrate: N (dove N è maggiore di prima, perché 7.1 aggiunge le capabilities di Notes, Identity, e alcune varianti di media processing).

Pianificazione del rollback

Anche se improbabile, un rollback può rendersi necessario. Va preparato in anticipo: snapshot del database, backup della cartella wp-content, snapshot della tabella wp_options. Il rollback in-place è teoricamente possibile se l'aggiornamento non ha modificato lo schema del database, ma realisticamente si preferisce un ripristino del backup pre-update piuttosto che un tentativo di downgrade.

Come aggiornare in produzione, in ordine

L'ordine corretto è importante. Mai aggiornare WordPress core durante un picco di traffico (tipico orario di pubblicazione per un editore) e mai senza backup completo verificato.

Step 1: backup completo verificato

# backup database (struttura + dump)
wp db export /var/backups/wp-pre-71-$(date +%Y%m%d-%H%M).sql --allow-root

# verifica dimensione e checksum
ls -lh /var/backups/wp-pre-71-*.sql
sha256sum /var/backups/wp-pre-71-*.sql

# backup wp-content (più pesante, escludere cache)
rsync -a --exclude='cache/' --exclude='uploads/backwpup*' \
  /var/www/wp-content/ /var/backups/wp-content-pre-71-$(date +%Y%m%d-%H%M)/

Step 2: aggiornamento in staging

Si aggiorna prima lo staging, si attende almeno 24 ore, si verifica assenza di regressioni. Le verifiche da fare in staging sono: test del flusso immagini completo (Chrome e Safari), test della Abilities API come visto sopra, test di creazione di un post con Note, verifica del Site Editor Identity screen, test di un'operazione AI se il sito usa il Bridge.

Step 3: aggiornamento in produzione in finestra a basso traffico

# aggiornamento core
wp core update --version=7.1 --allow-root

# verifica post-update
wp core version --allow-root
# atteso: 7.1

# aggiornamento database (idempotente)
wp core update-db --allow-root

Step 4: monitoraggio prime 72 ore

Le prime 72 ore sono le più critiche. WordPress 7.1, secondo l'analisi di Kinsta, ha un profilo di rischio basso ma non zero: qualche plugin di terze parti potrebbe avere regressioni, specialmente nella gestione di immagini client-side. Il monitoraggio minimo consigliato è triplo: log degli errori PHP con wp config get WP_DEBUG_LOG, log di wp_remote_request() per le chiamate esterne che il Bridge AI può fare, e log dello storage locale wp-content/debug.log con WP_DEBUG attivo temporaneamente.

Casi speciali: siti ad alto traffico e WooCommerce

Siti ad alto traffico

Per i siti editorali con 500.000+ visite al mese, l'aggiornamento a 7.1 merita un rollback automatico basato su metriche. La logica è: se entro 30 minuti dall'aggiornamento il TTFB p95 sale sopra una soglia, si attiva automaticamente il ripristino dello snapshot.

<?php
/**
 * Plugin: monitor post-update WP 7.1
 * Verifica TTFB p95 e notifica via email se supera soglia
 */

defined( 'ABSPATH' ) || exit;

class Post_71_Monitor {

    private const THRESHOLD_MS = 800;
    private const CHECK_WINDOW  = 60; // secondi

    public function register(): void {
        add_action( 'admin_init', array( $this, 'check_post_update' ) );
    }

    public function check_post_update(): void {
        if ( ! get_option( 'wp_71_updated_at' ) ) {
            return;
        }

        $updated_at = (int) get_option( 'wp_71_updated_at' );
        if ( time() - $updated_at > self::CHECK_WINDOW ) {
            delete_option( 'wp_71_updated_at' );
            return;
        }

        $samples = get_option( 'wp_71_ttfb_samples', array() );
        if ( count( $samples ) < 10 ) {
            return;
        }

        sort( $samples );
        $p95 = $samples[ (int) ( count( $samples ) * 0.95 ) ];

        if ( $p95 > self::THRESHOLD_MS ) {
            wp_mail(
                get_option( 'admin_email' ),
                sprintf( '[ALERT] WP 7.1 TTFB p95=%.0fms', $p95 ),
                sprintf( 'Rilevato degradazione post-update. Valore p95: %.0fms (soglia: %dms). Valutare rollback.', $p95, self::THRESHOLD_MS )
            );
            delete_option( 'wp_71_updated_at' );
        }
    }
}

add_option( 'wp_71_updated_at', time(), '', false );
( new Post_71_Monitor() )->register();

WooCommerce

Per i negozi WooCommerce, il rischio principale è nella gestione delle immagini prodotto client-side. WooCommerce genera molte varianti immagine (shopthumbnail, shopcatalog, shop_single) e plugin di terze parti possono intercettare il flusso. L'aggiornamento andrebbe fatto in orario di chiusura del negozio con annuncio ai clienti, e va testato in staging con un catalogo realistico (almeno 100 prodotti, immagini di dimensioni diverse, SKU con varianti).

Cosa monitorare dopo l'aggiornamento

Tre metriche di sistema

La prima è il TTFB per pagine archivio, che in 7.1 può variare per via della cache del core. Va monitorato con uno strumento di synthetic monitoring (Pingdom, Better Uptime) e tramite il cron di base di WordPress stesso. La seconda è il tempo medio di upload di un'immagine, perché su Chrome 137+ la nuova pipeline client-side dovrebbe alleggerire il server. La terza è il tasso di errore delle chiamate AI, perché la Abilities API ora matura può cambiare il modo in cui il Bridge risponde.

Tre metriche utente

La prima è il tasso di abbandono delle pagine di upload, perché una regressione lato editor potrebbe essere invisibile dai log PHP ma evidente agli utenti. La seconda è il Net Promoter Score interno raccolto dai clienti dopo 30 giorni. La terza è la velocità percepita di caricamento delle pagine archivio.

Audit del database

L'aggiornamento tocca una serie di tabelle wp_* e aggiunge le opzioni per le nuove funzionalità. Un audit settimanale nelle prime quattro settimane è una buona pratica.

# verifica opzioni aggiunte
wp option list --search="wp_71_*" --allow-root --format=table

# verifica tabelle nuove (atteso: wp_abilities, wp_ability_categories se non esistenti)
wp db query "SHOW TABLES LIKE 'wp_abilities%';" --allow-root
wp db query "SHOW TABLES LIKE 'wp_notes%';" --allow-root

Cosa fare se qualcosa va storto

Cache che non si pulisce

Il primo sintomo possibile è che la cache continui a servire contenuti pre-update. Soluzione: pulizia cache Litespeed/WP Super Cache/W3 Total Cache a mano via wp cache flush --allow-root. Per i siti Cloudflare, "Purge Cache" sullo zone settings.

Bridge AI che non risponde

Dopo l'aggiornamento il Bridge AI potrebbe richiedere una ri-autenticazione del Connector attivo. Sintomo: errori wp_ai_quota_exceeded anche con quota disponibile, oppure errori wp_ai_transient_error ripetuti. Soluzione: andare in Impostazioni → AI Connectors e ri-autenticare il provider scelto.

Note che non si attivano

La nuova Notes feature è opt-in. Per attivarla serve andare in Impostazioni → Generali → Experimental Features e abilitare "Notes for Editorial Teams". È un toggle esplicito, non un default.

Identity screen mancante

La schermata Identity nel Site Editor richiede un tema block-based. Se il sito usa ancora un tema classico (Twenty Twenty-One o precedente), la schermata Identity non appare: il tema classico non ha accesso alla Site Editor. Soluzione: passare a un tema block-based (Twenty Twenty-Five o Twenty Twenty-Six), o lasciare la gestione del brand ai customizer del tema.

Sintesi delle priorità per fascia di sito

Le fasce non sono normative: sono una guida operativa basata sul numero di plugin attivi e sulla complessità del flusso immagini.

Punti di contatto con gli articoli già pubblicati

WordPress 7.1 è complementare a diversi articoli già su mrtux.it:

• I Blocchi core introdotti con WordPress 6.9 sono la base di alcuni dei blocchi migliorati in 7.1.
• L'Abilities API pratica introdotta con 6.9 si integra con il Bridge AI introdotto con 7.0, formando l'architettura completa resa matura da 7.1.
• La panoramica su WordPress 7.0 Armstrong fornisce il contesto immediato precedente a 7.1.
• L'articolo sul WordPress Cron background tasks performance 2026 discute le attività in background che possono entrare in gioco dopo un aggiornamento importante.

Questi riferimenti permettono di costruire un piano di aggiornamento a 7.1 che tiene conto anche dell'architettura, non solo del singolo rilascio.

Domande frequenti

Quando sarà rilasciato WordPress 7.1? Il 19 agosto 2026 secondo Kinsta Blog. È una data confermata anche da make.wordpress.org/core.

Devo aggiornare tutti i plugin prima di aggiornare il core? Sì, è buona prassi. Plugin obsoleti su core nuovo sono una fonte classica di errori.

Client-Side Media Processing è attivo di default? Sì, in 7.1 il flusso di upload immagini è client-side di default per i browser che supportano WASM + DIP. Per gli altri browser il fallback è trasparente.

Posso disabilitare Client-Side Media Processing? Sì, via filtro wp_client_side_media_processing_enabled. È utile per test in staging o per casi in cui il team IT preferisce il flusso server-side.

Notes sostituisce plugin di team collaboration? Sostituisce quelli semplici. Per team con workflow editoriali complessi (assegnazioni, stati, deadline) i plugin dedicati (PublishPress, Edit Flow) restano più ricchi.

Riferimenti utili per approfondire

• WordPress 7.0 Armstrong: 6 novità per il workflow editoriale 2026 - panoramica sulla release precedente diretta di 7.1.
• Blocchi core WordPress 6.9 con AI: guida operativa 2026 - blocchi base da cui partono i blocchi migliorati in 7.1.
• Abilities API WordPress 6.9: guida operativa 2026 completa - l'API che 7.1 rende matura con il Bridge AI.
• WordPress cron 2026: come i task in background bloccano il sito - impatto delle attività background post-update.
• WP-Cron WordPress: ottimizzare i task background in produzione - setup operativo del cron in ambienti ad alto traffico.
• Toolchain agenzia WordPress moderna 2026: guida pratica completa - toolchain che semplifica l'aggiornamento in agenzie con molti siti.
• Kinsta Blog - What's new in WordPress 7.1 - articolo fonte per le novità di 7.1.
• make.wordpress.org/core - WordPress 7.1 Field Guide - guida ufficiale di rilascio della release.
• Kinsta Blog - Getting started with the WordPress Abilities API - approfondimento pratico sull'Abilities API che 7.1 rende matura.
• Plugin AI WordPress con MCP e abilities: pattern ufficiale 2026 - pattern Plugin Team per Bridge + Abilities.
• Documentazione Client-Side Media Processing su make.wordpress.org - riferimento canonico per DIP header e pipeline WASM.