Nota importante: questa pagina non conferma dettagli di rilascio, vulnerabilità, CVE o aggiornamenti automatici relativi a WordPress 7.0.2. Prima di intervenire, verifica nell’elenco ufficiale delle release WordPress che la versione esista, quali installazioni riguardi e quali istruzioni siano state pubblicate. La checklist qui sotto serve a organizzare un aggiornamento del core in modo prudente, soprattutto per siti che raccolgono contatti o gestiscono ordini.
Prima verifica: quale versione sta realmente eseguendo il sito?
Accedi a Bacheca > Aggiornamenti e annota la versione del core installata. Controlla anche se sono presenti aggiornamenti in sospeso e se l’hosting o il fornitore tecnico ha inviato comunicazioni relative al sito.
Non presumere che un aggiornamento automatico sia stato applicato o completato correttamente: il comportamento dipende dalla configurazione dell’installazione, dall’hosting e dalle regole impostate. Dopo ogni aggiornamento, la versione visualizzata e i percorsi principali del sito vanno controllati.
Decidi finestra, responsabilità e criterio di rollback
Un aggiornamento non è solo un clic: deve avere un responsabile, una finestra operativa e un piano di rientro. Prima di iniziare, identifica chi può accedere a WordPress, hosting, file del sito, database, backup, log e ambiente di staging.
- Annota versione del core, PHP, database, tema, plugin attivi, plugin personalizzati e must-use plugin.
- Individua i flussi che non possono interrompersi: form, email, login, area riservata, pagamenti, CRM, cookie banner, analytics e tag pubblicitari.
- Evita, se possibile, invii email, campagne a pagamento, modifiche editoriali concorrenti e fasce di alto volume per lead o ordini.
- Definisci chi autorizza un rollback, quale copia usare e come recuperare i dati entrati dopo il backup.
Verifica inoltre i requisiti tecnici nella pagina ufficiale Requirements di WordPress. La compatibilità effettiva non dipende soltanto dal core: tema, plugin, codice personalizzato e ambiente server vanno valutati nel singolo progetto.
Backup: una copia è utile solo se il ripristino è possibile
Prima dell’intervento crea un backup fresco e verifica che sia accessibile. Per un ripristino completo servono normalmente sia dati sia file: una sola delle due parti può non bastare a ricostruire correttamente il sito.
- Database del sito.
- File dell’installazione e cartella
wp-content, inclusi upload, temi e plugin. - File di configurazione, fra cui
wp-config.phpquando applicabile. - Istruzioni, credenziali e procedura per avviare il restore.
Backup dell’hosting, snapshot del server e backup applicativi possono avere copertura, frequenza e tempi di conservazione diversi. Se la procedura lo consente, prova il ripristino in un ambiente isolato. In alternativa, verifica almeno data della copia, posizione, accessi e tempi necessari a richiedere o avviare il recupero.
Un restore riporta il sito a uno stato precedente: non recupera automaticamente ordini, lead, iscrizioni o modifiche entrati dopo il punto di backup. Questo dato va considerato prima di scegliere il rollback.
Staging: testa senza sovrascrivere i dati del sito live
Lo staging è una copia non pubblica del sito, utile per un controllo preventivo. Dovrebbe essere il più vicino possibile alla produzione nel momento del test, ma non va trattato come una fonte da riversare automaticamente sul live.
Aggiorna inizialmente il solo core nello staging, annota l’esito e prova le funzioni critiche. Separare core, plugin e tema non è un obbligo universale, ma aiuta a isolare la causa di un errore e a rendere più leggibile un eventuale rollback.
Il rischio operativo più sottovalutato è la divergenza dei dati: mentre lo staging viene testato, nel sito live possono arrivare contatti, ordini, iscrizioni, commenti e modifiche editoriali. Un push che includa database o media può sovrascrivere informazioni entrate nel frattempo.
- Chiedi al provider se il deploy trasferisce file, database, media o una combinazione di questi elementi.
- Verifica quali tabelle, contenuti o impostazioni possono essere sovrascritti.
- Assegna una persona al presidio di lead e ordini durante la finestra di rilascio.
- Definisci come riconciliare i dati generati dopo il backup o durante il test.
Le funzioni di sincronizzazione variano tra provider. Per esempio, la documentazione di WordPress.com sul sync fra staging e produzione va letta come documentazione di quello specifico servizio, non come regola valida per tutti gli hosting.
Checklist di aggiornamento in produzione
- Conferma che backup e accessi necessari al restore siano disponibili.
- Verifica l’esito dei test in staging, se lo staging è usato.
- Accerta che cosa verrà distribuito e che non siano presenti modifiche non pianificate.
- Informa le persone coinvolte e sospendi gli interventi concorrenti quando necessario.
- Esegui un backup fresco immediatamente prima del rilascio.
- Aggiorna da Bacheca > Aggiornamenti oppure segui la procedura stabilita dall’hosting o dal team tecnico.
- Registra orario, versione precedente, versione finale e anomalie osservate.
- Evita di sommare molte modifiche non correlate, salvo una procedura già testata.
- Verifica che l’operazione sia conclusa e che la versione installata sia quella prevista.
Per le modalità generali di aggiornamento, consulta la documentazione ufficiale di WordPress. Le istruzioni del provider possono essere diverse se l’hosting gestisce aggiornamenti, snapshot o deploy in modo centralizzato.
Test dopo l’aggiornamento: verifica i percorsi che producono valore
Non fermarti alla home page. Un sito può apparire corretto pur avendo un form che non invia email, un login non funzionante o un checkout interrotto.
- Apri home page, pagine di atterraggio, menu, ricerca e pagine principali da desktop e mobile.
- Invia un test dai form e verifica messaggio a schermo, email ricevuta e inserimento nel CRM, se presente.
- Prova login, recupero password e area riservata.
- Per e-commerce, verifica prodotto, carrello, checkout, pagamento con una modalità sicura disponibile, email ordine e stock.
- Controlla cookie banner, analytics, tag pubblicitari e integrazioni essenziali.
- Esamina log PHP e server, se accessibili, e monitora lead, ordini ed email transazionali nelle ore successive.
Se disponi di competenze tecniche e accesso a WP-CLI, il comando wp core verify-checksums può essere un controllo aggiuntivo sull’integrità dei file core. Non sostituisce però i test funzionali. Consulta la documentazione WP-CLI prima di eseguirlo.
Se il sito non funziona o resta in manutenzione
Prima di modificare qualunque cosa, raccogli screenshot, orario, URL interessato, messaggi visualizzati e log disponibili. Evita modifiche improvvisate al database o sostituzioni manuali di file in produzione: possono rendere più difficile capire l’origine del problema.
In caso di aggiornamento interrotto, WordPress documenta anche il caso del file .maintenance. Intervieni sui file solo con accesso adeguato e dopo aver verificato che il processo non sia ancora in corso; segui la procedura riportata nella documentazione ufficiale sull’aggiornamento.
Se un flusso essenziale è compromesso, applica il piano di rollback concordato. Prima del restore valuta quali dati recenti dovranno essere recuperati o riconciliati. Per analizzare log, snapshot, compatibilità o errori server, coinvolgi l’hosting, il sysadmin o il fornitore WordPress responsabile dell’ambiente.
Domande frequenti
Il sito verrà aggiornato automaticamente a WordPress 7.0.2?
Non darlo per scontato. Controlla la versione in Bacheca, le comunicazioni dell’hosting e l’annuncio ufficiale della release. Le politiche di aggiornamento automatico possono dipendere dalla configurazione e dal servizio usato.
Devo aspettare lo staging?
Quando disponibile, lo staging è utile per un test essenziale. La durata e il livello di approfondimento dipendono dall’urgenza comunicata nella fonte ufficiale, dalla complessità del sito e dalla praticabilità del rollback.
Posso aggiornare core, plugin e tema insieme?
Può essere possibile, ma rende più difficile attribuire un malfunzionamento a una singola modifica. Per siti commerciali è generalmente più gestibile separare gli interventi, salvo una procedura già collaudata.
Il backup dell’hosting basta?
Dipende da contenuto, frequenza, conservazione, accessibilità e procedura di ripristino. Verifica questi aspetti prima dell’aggiornamento.
Cosa rischio sincronizzando staging e produzione?
Se la sincronizzazione include database o media, può sovrascrivere dati entrati nel live durante i test. Chiedi sempre al provider quali componenti vengono trasferiti e come gestire la riconciliazione.
