WordPress 7.0 RC2: checklist di test su staging

WordPress 7.0 RC2 non è il momento per fare click in produzione e sperare bene. È il momento per caricare una copia di staging del sito cliente, ripetere i flussi davvero importanti e scoprire prima dove si rompe il tema, quale plugin entra in conflitto o quale script manda in crisi il checkout.

Quando un sito passa da una versione all’altra, il problema non è quasi mai il core da solo. I guai nascono dall’interazione tra tema, plugin, cache, editor a blocchi, eventuali custom code e la versione PHP del server. Per questo la domanda giusta non è “posso aggiornare?” ma “cosa devo testare prima di promuovere l’aggiornamento?”.

Le release candidate di WordPress 7.0 sono uscite a pochi giorni di distanza: RC1 il 24 marzo 2026 e RC2 il 26 marzo 2026. La release 6.9.4 resta il riferimento stabile immediatamente precedente. Il flusso corretto è sempre lo stesso: backup, staging, test mirato, solo poi rollout. La guida ufficiale Updating WordPress mette il backup al primo posto, e non per forma.

La checklist che usiamo davvero

Area	Cosa controllare	Esito verde
Ambiente	Versione PHP, estensioni, memory limit, rewrite, cron	Parità ragionevole con la produzione
Tema	Homepage, singoli, archive, template custom, blocchi custom	Nessun layout rotto
Plugin critici	SEO, cache, form, SMTP, backup, cookie banner, membership	Nessun errore o warning
Flussi business	Login, ricerca, form, newsletter, checkout, pagine account	Funzionano senza regressioni
JavaScript	Console browser, network, blocchi, lazy load, modal, slider	Nessun errore JS critico
Performance	TTFB, LCP, CLS, query lente, errori PHP	Nessun peggioramento evidente
Rollback	Snapshot, restore, tempi di ritorno alla versione precedente	Piano chiaro e già provato

1. Congela il punto di partenza

Prima di toccare la versione core, fai tre cose:

• backup completo di file e database;
• annota la versione WordPress, la versione PHP e il set di plugin attivi;
• replica in staging il più possibile: stesso tema, stessi plugin, stessa logica di cache, stessi rewrite, stesso oggetto cache se lo usi in produzione.

Se lo staging ha meno plugin, una PHP diversa o una cache diversa, il test può mentire. Non stai verificando l’aggiornamento: stai verificando un ambiente diverso.

2. Testa ciò che rompe davvero

Nella pratica, i punti fragili sono quasi sempre gli stessi:

• home page e template principali;
• editor a blocchi, pattern, blocchi custom e shortcode legacy;
• menu, search, pagination e archivi;
• form di contatto e invio email;
• siti con login, aree riservate o membership;
• WooCommerce: catalogo, carrello, checkout, account, email ordine;
• plugin che toccano database, rewrite o integrazioni esterne.

Se il sito usa WooCommerce, il checkout è il test numero uno. Se il sito usa custom blocks, il blocco più delicato è il rendering lato editor e lato front-end. Se il sito invia email, controlla SMTP e code di consegna dopo l’aggiornamento, non solo il click del form.

3. Leggi i segnali di errore con criterio

Su staging non basta vedere che “la pagina si apre”. Devi cercare i segnali deboli:

• errori PHP nei log;
• warning e notice ripetuti;
• script bloccati in console;
• risorse 404 o 500;
• layout shift improvvisi;
• differenze tra mobile e desktop;
• tempi di caricamento peggiori sulle pagine più importanti.

4. Decidi con criteri go / no-go

Promuovi l’aggiornamento in produzione solo se puoi dire sì a queste domande:

1. il sito si comporta come prima nelle pagine critiche;
2. il tema non mostra regressioni visive;
3. i plugin indispensabili non generano errori;
4. le email partono davvero;
5. il checkout o i form di contatto funzionano;
6. hai un rollback testato, non solo immaginato.

Se anche una sola risposta è no, fermati. Il costo di un rollback pianificato è quasi sempre inferiore al costo di una regressione scoperta dal cliente.

Errori tipici che vediamo negli update fatti male

Le regressioni più comuni sono molto prevedibili:

• aggiornare il core senza testare i plugin di pagamento o di form;
• usare staging con PHP diversa dalla produzione;
• ignorare il browser console perché “la pagina si vede comunque”;
• non testare le email dopo il cambio versione;
• fare l’aggiornamento senza snapshot ripristinabile;
• promuovere in produzione il venerdì pomeriggio.

L’ultimo punto non è una battuta: è una strategia operativa scadente.

Domande frequenti

Conclusione

WordPress 7.0 RC2 è un buon promemoria: aggiornare non significa solo cambiare versione, significa verificare che il sito continui a vendere, raccogliere lead e funzionare senza sorprese. La differenza tra un update tranquillo e un’incidenza costosa è quasi sempre la qualità dello staging e la disciplina del test.

Se vuoi che il prossimo aggiornamento WordPress sia verificato prima di arrivare ai clienti, possiamo partire da un audit gratuito o da un servizio di hardening. La parte importante non è aggiornare prima degli altri: è aggiornare senza interrompere il lavoro del sito.

Fonti

• WordPress 7.0 Release Candidate 2
• WordPress 7.0 Release Candidate 1
• WordPress 6.9.4 Release
• Updating WordPress