Se il tuo sito aziendale gira ancora su WordPress 6.x, o su una 7.0 mai toccata, la domanda non è se aggiornare ma in che ordine farlo. La serie 7 cambia cose che si vedono poco dall’esterno ma pesano sui siti su misura: un AI Client nel core, una schermata Connectors per i servizi esterni, l’editor dei post sempre dentro un iframe e le immagini elaborate dal browser invece che dal server. In questo articolo descrivo il metodo che uso quando devo aggiornare WordPress 7 sui siti che sviluppo, ospito e mantengo, come lapidari.it e opticagheller.it: staging, PHP, plugin, test mirati e solo alla fine la produzione.
Cosa cambia davvero con WordPress 7.x
Per pianificare bisogna sapere cosa si sta installando. Riassumo i punti che, nel mio lavoro, richiedono un controllo concreto (le fonti sono in fondo a ogni paragrafo, conviene sempre confrontarle con le note ufficiali su wordpress.org):
- WordPress 7.0 introduce un AI Client nel core e una nuova schermata in Impostazioni > Connectors per gestire le connessioni a servizi esterni, provider AI compresi (spaziorc.com).
- WordPress 7.1 sposta l’elaborazione delle immagini caricate dal server al browser e rende l’editor dei post sempre incapsulato in un iframe (alessandroaili.it).
- WordPress 7.2 risulta pianificata per il 10 dicembre 2026. Il dato arriva da un blog di settore: prima di fissare una data di manutenzione lo verifico sul calendario di rilascio ufficiale.
Chi oggi non è almeno alla 7.1.2 dovrebbe pianificare l’aggiornamento adesso, partendo dalla versione di PHP, invece di inseguire la 7.2 a ridosso delle festività.
Il punto di partenza: PHP e inventario
Non aggiorno mai il core su un PHP vecchio. Prima porto il sito su una versione di PHP supportata, poi tocco WordPress. Ho già descritto questo passaggio nell’articolo su come aggiornare PHP su WordPress prima della fine di PHP 8.2; qui lo do per acquisito.
Il secondo passo è un inventario scritto, che per un sito su misura comprende:
- Tema: versione, blocchi personalizzati, eventuali script caricati nell’editor.
- Plugin: elenco completo, data dell’ultimo aggiornamento, compatibilità dichiarata con la serie 7.
- Codice custom: mu-plugin, hook su upload e media, integrazioni con servizi esterni.
- Flussi critici: cosa non deve rompersi. Su un sito con vendita di corsi è il checkout e l’accesso all’area riservata; su un sito con prenotazioni è il modulo di appuntamento.
Senza questa lista, i test diventano un giro casuale sul sito, e un giro casuale non trova i problemi che contano.
Staging su HestiaCP: una copia fedele, ma muta
Tutti i siti che gestisco girano sul mio hosting con HestiaCP, e lo staging lo creo lì: un sottodominio dedicato, copia dei file e del database, sostituzione degli URL con WP-CLI. Ne ho parlato più in generale in come gestisco l’hosting dei clienti con HestiaCP.
La parte che molti saltano è rendere lo staging muto:
- Blocco l’indicizzazione e proteggo lo staging con autenticazione HTTP, così non finisce su Google come contenuto duplicato.
- Disattivo l’invio email, altrimenti un test di ordine o prenotazione manda notifiche a clienti veri.
- Metto i pagamenti in modalità test e scollego i webhook di produzione: un webhook che punta allo staging, o viceversa, genera stati incoerenti.
- Disattivo le chiavi API reali verso servizi esterni, comprese quelle che finirebbero nella schermata Connectors.
Prima di qualsiasi intervento faccio un backup completo della produzione, file e database, e verifico che sia ripristinabile. Un backup mai provato non è un piano di rollback.
I test che faccio su un tema WordPress su misura
Editor sempre in iframe
Con l’editor isolato in un iframe, il codice che dava per scontato di lavorare sullo stesso documento della pagina di amministrazione può smettere di funzionare. Controllo in particolare:
- i blocchi personalizzati del tema: registrazione, stili e script devono arrivare dentro l’iframe;
- gli stili dell’editor: se prima venivano caricati in modo non standard, nell’iframe il contenuto appare senza formattazione;
- i plugin che aggiungono pannelli o script all’editor, ad esempio per SEO o campi personalizzati.
Il test pratico è semplice: apro in staging gli articoli e le pagine più complessi, li modifico, salvo, e confronto il risultato pubblico con la produzione.
Immagini elaborate nel browser
Se la generazione delle miniature avviene lato browser, ciò che prima succedeva sul server va ricontrollato. Verifico:
- che le dimensioni immagine personalizzate definite dal tema vengano ancora generate correttamente;
- il comportamento di eventuale codice che interviene dopo l’upload (ridimensionamenti, watermark, ottimizzazioni);
- i plugin di compressione, che potrebbero lavorare in modo diverso o diventare ridondanti;
- l’upload dai dispositivi reali di chi gestisce i contenuti: un catalogo con molte foto caricate da un portatile datato è un caso diverso da un test sul mio computer.
Flussi di business
Infine ripercorro a mano i flussi dell’inventario: acquisto in modalità test, login nell’area riservata, invio del modulo di prenotazione, ricezione della conferma (in una casella di test). Sono pochi passaggi, ma sono quelli per cui il sito esiste.
AI Client e Connectors: cosa attivare, e chi decide
La presenza di un AI Client nel core non significa che un sito aziendale debba usarlo. Per ogni cliente la mia regola è: nessun connettore attivo senza una decisione esplicita. Dopo l’aggiornamento controllo cosa compare in Impostazioni > Connectors e quali plugin sfruttano l’infrastruttura AI, poi discuto con il titolare tre punti:
- Quali dati escono: testi delle pagine, descrizioni prodotto, dati di clienti? Se ci sono dati personali, entra in gioco il GDPR, con informativa e accordo con il fornitore.
- Chi può configurare i connettori: limito l’accesso agli amministratori e, dove serve, creo ruoli con permessi ridotti per chi scrive contenuti.
- Dove stanno le chiavi API: preferisco che le credenziali sensibili non siano gestite dal pannello da utenti diversi da chi ne risponde, e le tratto come qualsiasi altro secret dell’infrastruttura.
Se il cliente vuole usare l’AI per generare testi, ricordo anche gli obblighi di trasparenza sui contenuti generati, tema che ho trattato in etichettatura dei contenuti AI nel marketing.
Il passaggio in produzione e il rollback
Quando lo staging è verde, la produzione segue una sequenza fissa:
- Backup fresco subito prima dell’intervento.
- Finestra a basso traffico, concordata con il cliente.
- Aggiornamento di plugin e tema prima del core, nello stesso ordine testato.
- Aggiornamento del database se richiesto, poi svuotamento delle cache.
- Ripetizione rapida dei test sui flussi critici, questa volta in produzione.
- Monitoraggio dei log PHP e del server nelle ore successive.
Se qualcosa va storto, il ripristino è dal backup appena fatto, non un tentativo di riparare a caldo. Per chi vuole il quadro completo della manutenzione ordinaria, rimando a hardening, backup e aggiornamenti di WordPress.
FAQ
Posso aggiornare WordPress 7 direttamente dalla bacheca?
Tecnicamente sì. Su un sito con tema su misura, e-commerce o prenotazioni lo sconsiglio: senza staging scopri i problemi quando li vedono i clienti.
Devo attivare le funzioni AI dopo l’aggiornamento?
No. Aggiornare il core e decidere se usare provider AI sono due scelte separate. La seconda richiede valutazioni su dati, costi e responsabilità.
Conviene aspettare la 7.2?
Se sei fermo prima della 7.1.2, no: il salto diventa più ampio e più rischioso. Meglio allinearsi ora e affrontare la 7.2 come aggiornamento ordinario.
Quanto dura un intervento del genere?
Dipende da quanto codice custom e quanti plugin ci sono. L’inventario iniziale serve proprio a stimarlo prima di iniziare, non dopo.
Un sito gestito end-to-end
Aggiornare WordPress 7 non è un clic: è il punto in cui sviluppo, hosting e manutenzione devono parlarsi. È il motivo per cui seguo i siti dei clienti dall’inizio alla fine, dal tema su misura al server su cui girano. Se hai un sito WordPress o una web app da sviluppare, aggiornare o prendere in gestione, scrivimi qui e partiamo dall’inventario.
