Un aggiornamento automatico può rompere un sito WordPress senza che nessuno abbia toccato niente: quando succede, il primo sospetto è un plugin incompatibile e il primo intervento è rinominare la sua cartella via FTP. Stamattina c’è una pagina bianca con un errore critico, oppure una scritta che dice che il sito è in manutenzione e non se ne esce. Non hai toccato niente — ed è proprio questo il punto: qualcosa si è aggiornato da solo.
Qui trovi che cosa aggiorna WordPress senza chiederti niente, perché a volte lo aggiorna anche il tuo hosting senza che tu lo sappia, cosa si rompe davvero quando va male e come si torna indietro. C’è anche il file che tiene il sito in «manutenzione» per giorni, e come si cancella.
In una frase: gli aggiornamenti automatici non sono uno ma quattro — core minore (attivo da sempre), core maggiore, plugin e tema, e quelli del pannello del tuo hosting, che è il più delle volte la causa. Le costanti in wp-config.php non li fermano tutti. Quando un aggiornamento va male, il primo sospetto è il plugin incompatibile e il primo intervento è rinominare la sua cartella via FTP. E se il sito resta bloccato in manutenzione, si cancella il file .maintenance.
Cosa aggiorna WordPress da solo?
La confusione nasce dal fatto che «aggiornamento automatico» significa tre cose diverse, introdotte in momenti diversi. Nella documentazione ufficiale è scritto così: da WordPress 3.7 le versioni minori e di sicurezza si applicano da sole, in background, senza che tu debba fare niente («non devi muovere un dito», dice il testo).
Per il resto bisogna arrivare al 2020. Il 5.5 introduce l’aggiornamento automatico di plugin e temi, ma spento di default e acceso uno per uno dalla schermata dei plugin. Il 5.6 aggiunge la possibilità di attivare l’aggiornamento automatico anche per le versioni maggiori del core, con una casella nella schermata Aggiornamenti (l’annuncio ufficiale su Make WordPress Core). Quindi: minori sì da sempre, maggiori e plugin solo se qualcuno li ha attivati.
I quattro strati che possono aggiornare il tuo sito
Questa è la parte che spiega il mistero del sito cambiato da solo: gli aggiornamenti possono partire da quattro posti indipendenti, e controllarne uno non ferma gli altri. È il caso raccontato in una discussione su r/Wordpress, dove un utente aveva messo in wp-config.php la riga per disattivare tutto e si è comunque trovato WooCommerce aggiornato: «nonostante define( 'AUTOMATIC_UPDATER_DISABLED', true ); in wp-config, a cosa non ho pensato?». La risposta più votata del thread è la stessa che dà il primo indizio quasi ogni volta: «controlla nel tuo pannello di hosting se gli aggiornamenti automatici sono attivi — nella mia esperienza è una delle cause più comuni».
| Strato | Dove si controlla | Cosa copre |
|---|---|---|
| Core, versioni minori e sicurezza | Nessun intervento: sono attive per default | Correzioni di sicurezza e bug fix. Non conviene spegnerle |
| Core, versioni maggiori | Bacheca → Aggiornamenti (dal 5.6) oppure `WP_AUTO_UPDATE_CORE` | Passaggi di versione maggiore, quelli con i cambi più visibili |
| Plugin e tema | Bacheca → Plugin (uno per uno, dal 5.5) | Aggiornamenti dei singoli plugin e del tema attivo |
| Pannello dell’hosting | cPanel / WP Toolkit, o la gestione del servizio | Può aggiornare core, plugin e tema al posto tuo, indipendentemente dalle impostazioni di WordPress |
Su quest’ultimo strato la documentazione non può aiutare, perché dipende dal fornitore. Un utente del thread lo dice senza giri di parole: se usi cPanel, guarda le opzioni dell’installazione; se hai un servizio «WordPress gestito», gli aggiornamenti arrivano e basta — «vengono aggiornati per mantenere l’integrità dell’infrastruttura». Su questo vale la pena sapere una cosa: mantenere aggiornato un sito non è solo ordine. In alcuni contesti è un obbligo — chi vende con un carrello deve passare scansioni di vulnerabilità periodiche, e il software vecchio fa scattare la segnalazione. La guida su come scegliere i plugin e quella su cosa chiedere a un hosting WordPress servono anche a questo: sapere chi decide gli aggiornamenti.
«Manutenzione WordPress» quasi mai significa questo
Vale la pena dirlo perché cambia il modo in cui si cerca: chi digita «manutenzione wordpress» su Google non sta cercando la manutenzione, sta cercando la modalità manutenzione — la pagina che si mostra mentre si lavora al sito. I suggerimenti di ricerca lo confermano: fra le prime cinque proposte ci sono «modalità manutenzione WordPress», «pagina manutenzione WordPress» e «mettere in manutenzione WordPress».
Se invece la modalità manutenzione ti serve davvero — perché stai rifacendo il sito e vuoi una pagina decente — la strada normale è un plugin che la attiva e la disegna, oppure una pagina di cortesia con un codice di risposta 503. La modalità di WordPress, quella che compare durante gli aggiornamenti, non è personalizzabile: serve a un caso solo, e non è quello che si vuole mostrare ai visitatori.
I due temi però si toccano in un punto preciso, e non è una coincidenza: quando WordPress si aggiorna mette il sito in manutenzione da solo. Se l’aggiornamento non finisce, quel blocco resta. È il primo posto da guardare quando il sito sembra «in manutenzione per sempre», ed è l’argomento del capitolo successivo.
Un dettaglio pratico che vale più di ogni registro: WordPress manda un’email quando si aggiorna da solo. È così che molte persone scoprono il problema con un giorno di ritardo — nel forum italiano c’è chi ha trovato in casella un messaggio con oggetto «Il tuo sito è aggiornato a WordPress 6.0.9» e, da lì, la certezza della data. Quella email è il punto di partenza della diagnosi: dice che il core si è aggiornato e quando, quindi restringe il campo a quello che è cambiato dopo.
Il file che tiene il sito in manutenzione per sempre
Si chiama .maintenance, sta nella cartella principale dell’installazione, e WordPress lo crea all’inizio di ogni aggiornamento: finché c’è, ogni pagina risponde con la frase «Brevemente non disponibile per manutenzione programmata». Alla fine dell’aggiornamento WordPress lo cancella da solo. Se l’aggiornamento si interrompe, il file resta — e il sito resta bloccato anche se sotto è perfettamente funzionante.
Non è un dettaglio da addetti ai lavori: è talmente centrale che la procedura ufficiale di aggiornamento manuale gli dedica un passaggio apposta, intitolato «Step 1.5: Remove .maintenance file». Il rimedio è quello che dice il nome: si entra con il gestore file dell’hosting (o via FTP), si vede il file .maintenance nella cartella principale, si cancella, si ricarica il sito. È l’intervento più rapido di tutto questo articolo, e risolve un caso che sembra gravissimo.
Cosa si rompe davvero dopo un aggiornamento?
Le cause sono poche e i sintomi sono riconoscibili. Questa è la mappa che serve a orientarsi in cinque minuti, senza toccare niente a caso.
| Cosa si è rotto | Come si presenta | Primo controllo |
|---|---|---|
| Un plugin incompatibile con la nuova versione | Errore critico, pagina bianca, a volte solo bacheca o solo il sito | Rinominare via FTP la cartella del plugin sospetto in `wp-content/plugins` |
| Il tema non regge la nuova versione | Il sito si vede ma è sbagliato, o va in errore solo in certe pagine | Attivare un tema di default e vedere se il problema sparisce |
| Il database è rimasto indietro | Il sito dà errore anche se file e versioni sembrano a posto | Controllare la sezione Database del pannello e chiedere al fornitore se lo schema è allineato |
| Il file `.maintenance` è rimasto lì | Ogni pagina dice che il sito è in manutenzione | Cancellare `.maintenance` dalla cartella principale |
| La cache serve la pagina vecchia | Le correzioni non si vedono, sembra che nulla sia cambiato | Svuotare la cache del sito e quella del browser |
Il caso del plugin è di gran lunga il più frequente, e ha una firma precisa nel forum italiano. Un utente racconta che «l’aggiornamento automatico non è riuscito» e che, provando quello manuale, «si è bloccato tutto il sito» con l’errore critico (il topic sul forum italiano). Quando non si riesce più a entrare in bacheca la disattivazione non si fa dal pannello: si rinomina la cartella del plugin via FTP o dal gestore file. È il caso di chi ha scoperto l’accaduto da un’email con oggetto «Il tuo sito è aggiornato a WordPress 6.0.9» (il topic sul forum italiano). E c’è un caso più insidioso, che nessuna guida nomina. Un utente con il sito attivo da otto anni ha scoperto che «il database non era aggiornato e non collimava con gli aggiornamenti avvenuti in automatico»: file nuovi, schema vecchio (il topic sul forum italiano.
Come si torna indietro dopo un aggiornamento?
Qui serve chiarezza, perché molte guide promettono più di quanto esista. Per il core non esiste un pulsante «annulla»: la documentazione ufficiale dice una cosa sola — se dopo l’aggiornamento hai problemi, ripristini il backup oppure prendi i file della versione precedente dall’archivio delle release. Il rollback del core è, in pratica, un ripristino: se non hai una copia recente, non torni indietro. È il motivo per cui il backup non è un consiglio ma la condizione per poter aggiornare tranquillamente (il metodo completo è qui).
Per plugin e tema la situazione è migliore: il ripristino della singola versione si fa con un plugin dedicato, oppure reinstallando la versione precedente dal file zip. È la differenza che rende sensata una strategia semplice: aggiornare prima plugin e temi su un ambiente di prova, e solo dopo il core, così quando qualcosa si rompe si sa cosa lo ha rotto. Se il sito vive su un solo server, senza copia e senza prova, l’unico modo di scoprirlo è rompere la produzione. Gli aggiornamenti di versione sono anche un buon momento per misurare: se dopo un aggiornamento il sito è più lento di prima, il passo successivo è capire dove si perde tempo, non tornare indietro a caso.
Si possono scegliere o spegnere gli aggiornamenti automatici?
Sì, ma con tre avvertenze. La prima: le impostazioni del pannello e quelle di wp-config.php non coprono lo strato dell’hosting, quindi un sito può continuare ad aggiornarsi anche dopo aver «disattivato tutto». La seconda: le due costanti fanno cose diverse. AUTOMATIC_UPDATER_DISABLED spegne l’aggiornamento automatico in generale — la documentazione la descrive come una scelta da fare «prima di una versione maggiore, per avere il tempo di provare su un ambiente di sviluppo». WP_AUTO_UPDATE_CORE invece decide il core: false li blocca tutti, true li abilita tutti, 'minor' tiene solo le minor (ed è il valore di default).
La terza, e la più importante: bloccare le versioni minori e di sicurezza non è una scelta prudente, è un rischio — sono proprio quelle che chiudono le falle. Se serve tempo, si blocca la maggiore e si tiene la minore. Se il problema sono i plugin, si spegne l’aggiornamento automatico di quel plugin, non di tutti.
Il controllo da fare prima di aggiornare, in sei passi
- Backup completo (file e database) e verifica che il ripristino sia già stato provato almeno una volta.
- Leggi le note di versione dell’aggiornamento: dicono cosa cambia e quali versioni minime servono.
- Controlla la versione di PHP e le estensioni attive nel pannello: i requisiti ufficiali indicano PHP 8.3 o superiore, MariaDB 10.11 o MySQL 8.0, e un aggiornamento può richiedere una versione più recente.
- Aggiorna prima plugin e temi su un ambiente di prova, poi il core: se qualcosa si rompe, sai già chi è stato.
- Aggiorna con il sito scarico di traffico e con la cache esclusa, per non servire pagine a metà.
- Dopo l’aggiornamento, apri il sito da fuori (non da amministratore collegato) e controlla home, un articolo e il modulo di contatto.
In sintesi
Gli aggiornamenti automatici non sono una cosa sola: le versioni minori e di sicurezza arrivano da sole dal 3.7, plugin e temi li accendi tu uno per uno, il core maggiore è una scelta, e il pannello dell’hosting può fare tutto questo al posto tuo — è la causa che sfugge perché non è scritta da nessuna parte dentro WordPress. Quando un aggiornamento va male, la sequenza è: plugin incompatibile (cartella rinominata via FTP), database rimasto indietro, `.maintenance` dimenticato, cache vecchia. E per il core non esiste il pulsante annulla: esiste il backup. Chi aggiorna senza copia non sta facendo manutenzione, sta scommettendo.
Domande frequenti
- Come si fermano gli aggiornamenti automatici di WordPress?
- Con tre controlli, perché gli strati sono indipendenti: la casella per le versioni maggiori nella schermata Aggiornamenti (dal 5.6) e l’interruttore per ogni singolo plugin (dal 5.5); poi le costanti in wp-config.php, AUTOMATIC_UPDATER_DISABLED (tutto) e WP_AUTO_UPDATE_CORE (solo il core: false, true o ‘minor’); e infine le impostazioni nel pannello dell’hosting, che spesso è lo strato che continua ad aggiornare.
- Perché il sito è rimasto in manutenzione?
- Perché è rimasto il file .maintenance nella cartella principale dell’installazione: WordPress lo crea quando inizia ad aggiornare e lo cancella quando finisce. Se l’aggiornamento si interrompe, il file resta e il sito continua a rispondere «in manutenzione» anche se sotto funziona. Si cancella dal gestore file dell’hosting o via FTP.
- Come si torna alla versione precedente di WordPress?
- Non con un pulsante: per il core non esiste un rollback integrato. Le due strade ufficiali sono ripristinare un backup oppure rimettere i file della versione precedente presi dall’archivio delle release di WordPress.org. Per plugin e tema, invece, il ripristino della singola versione si fa con un plugin dedicato o reinstallando lo zip precedente.
- Ho disattivato gli aggiornamenti ma i plugin si aggiornano lo stesso: perché?
- Perché le impostazioni di WordPress non controllano lo strato dell’hosting. Nei pannelli cPanel (WP Toolkit) e nei servizi «WordPress gestito» gli aggiornamenti possono essere applicati dal fornitore, indipendentemente da quello che hai impostato in bacheca o in wp-config.php. Va controllato anche lì.
- Conviene disattivare gli aggiornamenti automatici di sicurezza?
- No. Le versioni minori e di sicurezza sono quelle che chiudono le falle note, e sono attive per default da WordPress 3.7 proprio per questo. Se serve tempo per testare, si blocca la versione maggiore e si mantiene la minore; oppure si spegne l’aggiornamento automatico del singolo plugin che dà problemi, non di tutti.
- Un aggiornamento può rompere il database?
- Il database non si danneggia, ma può restare indietro rispetto ai file: è il caso di un sito che dopo un aggiornamento automatico non si apriva più, perché lo schema non coincideva con la nuova versione. In quel caso il controllo è nella sezione Database del pannello di hosting, e la richiesta al fornitore è di verificare l’allineamento dello schema.
Lascia un commento