WordPress 7.0: come aggiornare in produzione senza downtime

WordPress 7.0, rilasciato ufficialmente il 20 maggio 2026, è la major release più impattante dal 5.0: real-time collaboration sui contenuti, amministrazione ridisegnata con il sistema DataViews, requisiti minimi innalzati a PHP 7.4 e una nuova AI infrastructure nativa. Per chi gestisce siti in produzione, questo significa una cosa sola: la finestra di errore si riduce, perché il delta tra un sito WordPress 6.x e 7.0 attraversa stack, plugin e template.

L'approccio "aggiorno e vedo cosa succede" non regge più. Serve una procedura ingegneristica, ripetibile, con rollback misurato. In questa guida ti spiego il metodo che usiamo sui siti in produzione dei nostri clienti, con i punti di attenzione specifici introdotti dal 7.0.

Se vuoi invece una panoramica completa di tutte le novità, puoi leggere la nostra guida completa a WordPress 7.0. Qui ci concentriamo solo sull'operatività dell'aggiornamento.

I tre rischi specifici di WordPress 7.0

Prima di toccare la produzione, mappa i rischi concreti introdotti da questa release. WordPress 7.0 non è un aggiornamento incrementale: cambia abbastanza sotto al cofano da rendere insufficienti le checklist del 6.x.

• Stack non più compatibile — Il core richiede PHP 7.4 minimo e MySQL 8.0+. Hosting datati (PHP 7.2, MariaDB 10.2) vengono tagliati fuori. Verificare prima se il proprio provider ha già aggiornato la versione di PHP disponibile.
• Temi block-based con override profondi — I temi Full Site Editing che facevano largo uso di hook personalizzati su block templates possono rompersi a causa del nuovo Block Locking API. I layout che "forzavano" proprietà ora potrebbero entrare in conflitto.
• Plugin di terze parti non pronti — Molti plugin usano admin_print_footer_scripts, manage_posts_extra_tablenav e altri hook legacy. La nuova interfaccia DataViews può renderli invisibili o non funzionanti. Serve un audit plugin per plugin.

Architettura minima per aggiornare senza downtime

Prima ancora di pensare a "come aggiornare", serve un'architettura che lo permetta. Se il sito è su un singolo server condiviso senza staging, l'obiettivo zero downtime è irrealistico. Ecco cosa serve.

1. Un ambiente di staging vero, non una copia a mano

Lo staging deve essere una replica bit-per-bit della produzione: stesso PHP, stesso MySQL, stessi plugin, stesse versioni, stesso tema child. Se cloni a mano e ti dimentichi il file wp-config.php o il cron di sistema, stai facendo theatre, non devops.

Un setup minimo per iniziare: usa container Docker per PHP localmente e poi replica la configurazione sul server di staging. La parola chiave è parità ambientale: se produzione gira su PHP 8.2 con OPcache attivo, anche lo staging deve girare così.

2. Backup verificati e ripristinabili

Un backup che non hai mai provato a ripristinare non è un backup, è una preghiera. Prima dell'aggiornamento a 7.0:

• Backup completo di file e database, non incrementale
• Ripristino di prova su un terzo ambiente (anche locale) entro 7 giorni
• Conservazione off-site per almeno 30 giorni

3. Accesso SSH e WP-CLI sul server di produzione

Operare da browser con la pagina di aggiornamento del backend significa: timeout, lock parziali, modalità manutenzione che resta attiva se qualcosa va storto. Con WP-CLI puoi gestire tutto da terminale, anche su connessioni instabili. Verifica che wp --info risponda prima di iniziare.

La procedura operativa in 8 step

Una volta che l'architettura è in piedi, l'aggiornamento vero e proprio è una checklist ripetibile. Segui gli step nell'ordine indicato.

Step 1 — Audit plugin e temi

Scarica un export JSON di tutti i plugin e temi installati (wp plugin list --format=json). Per ognuno verifica:

• Data di ultimo aggiornamento: se >12 mesi, rischio alto
• Compatibilità dichiarata con PHP 8.x: se non c'è, rischio altissimo
• Test contro WordPress 7.0 RC4 su staging (WordPress.org rilascia i release candidate proprio per questo)

Step 2 — Clona la produzione sullo staging

Copia file + database. Modifica solo wp-config.php per puntare al nuovo DB e cambia gli URL in siteurl e home con WP-CLI:

# clona database di produzione sullo staging
wp db export /tmp/staging_db.sql --allow-root
scp /tmp/staging_db.sql staging:/tmp/
ssh staging 'wp db import /tmp/staging_db.sql --allow-root'

# aggiorna URL sullo staging
ssh staging "wp option update siteurl 'https://staging.example.com' --allow-root"
ssh staging "wp option update home 'https://staging.example.com' --allow-root"

Step 3 — Aggiorna prima plugin e temi sullo staging

Questo è il punto in cui emergono i conflitti reali. Aggiorna un plugin alla volta, testando dopo ognuno. Su WordPress 7.0 la regola è: se un plugin ha una versione compatibile con 7.0, prendila; se non ce l'ha, congelalo e documenta la deroga. I plugin bloccanti vanno sostituiti, non disattivati: una disattivazione silenziosa di un plugin SEO o di cache può rompere il sito in modi non immediatamente visibili.

Step 4 — Aggiorna il core a 7.0 sullo staging

Solo dopo che plugin e temi sono puliti. Usa WP-CLI con --skip-themes e --skip-plugins per isolare l'aggiornamento del core:

# aggiorna solo il core WordPress, lasciando stare plugin e temi
wp core update --skip-themes --skip-plugins --allow-root

# poi rilancia gli aggiornamenti di plugin e temi separatamente
wp plugin update --all --allow-root
wp theme update --all --allow-root

Step 5 — Test funzionali sullo staging

Non "visito la home e mi sembra ok". Serve un test funzionale:

• Login come editor, autore, amministratore: ogni ruolo vede il backend corretto?
• Crea un articolo di prova con tutti i blocchi che usi (cover, gallery, tabelle, group/columns)
• Effettua un acquisto di test se gestisci WooCommerce
• Controlla i log PHP (/var/log/php-fpm/) e gli errori 5xx su Nginx/Apache
• Verifica l'output dei form di contatto e delle newsletter

Step 6 — Misura i tempi

Sullo staging, cronometra quanto dura ogni fase. L'aggiornamento core su 7.0 su un sito medio è di circa 30-90 secondi, ma il delta arriva dalla cache: invalidazione oggetti, ricostruzione autoload, rigenerazione rewrite rules. Pianifica una finestra di 5-10 minuti per il "passaggio" in produzione.

Step 7 — Esegui l'aggiornamento in produzione

Quando staging è verde, ripeti la stessa sequenza in produzione. Sequenza comandi:

# 1. backup di sicurezza immediato
ssh prod "wp db export /var/backups/wp_pre70_$(date +%Y%m%d).sql --allow-root"

# 2. attiva manutenzione
ssh prod "wp maintenance-mode activate --allow-root"

# 3. aggiorna il core
ssh prod "wp core update --skip-themes --skip-plugins --allow-root"

# 4. aggiorna plugin e temi uno a uno
ssh prod "wp plugin update --all --allow-root"
ssh prod "wp theme update --all --allow-root"

# 5. disattiva manutenzione
ssh prod "wp maintenance-mode deactivate --allow-root"

La finestra in cui il sito mostra la pagina "Sito in manutenzione" è idealmente sotto i 60 secondi: il tempo necessario a scaricare il nuovo core, decomprimerlo, aggiornare il DB e spegnere la modalità. Per ridurla, puoi pre-scaricare il pacchetto del core sul server ed eseguire un aggiornamento "minore" da file system.

Step 8 — Smoke test post-aggiornamento

Subito dopo aver spento la manutenzione, esegui:

• Verifica HTTP 200 su homepage, una pagina interna, il backend (wp post list via WP-CLI)
• Controlla i log delle ultime 5 minuti: nessun errore fatale PHP o MySQL?
• Apri Chrome DevTools, disabilita cache, ricarica: la pagina risponde in <1s?
• Controlla che i cron di sistema siano partiti (wp cron event list)

Strategia di rollback: il piano B

Nonostante tutta la preparazione, può succedere che qualcosa si rompa. Avere un rollback misurato è la differenza tra un'ora di stress e un downgrade in 10 minuti. Le opzioni sono tre, in ordine di robustezza.

Confronto rapido delle tre opzioni di rollback

Prima di scegliere, valuta pro, contro e casi d'uso. La soluzione giusta dipende da quanto tempo hai e da quale rischio devi mitigare.