Configurare gli aggiornamenti automatici del core di WordPress (WP_AUTO_UPDATE_CORE)

Da WordPress 3.7, la piattaforma aggiorna parti di se stessa automaticamente senza che nessuno clicchi nulla. La maggior parte dei proprietari di siti ne è vagamente consapevole, ma pochi hanno un quadro chiaro di cosa viene esattamente aggiornato, quando e come modificare l'impostazione predefinita. Questa guida attraversa i quattro livelli di aggiornamenti automatici che supporta il core di WordPress, cosa fa effettivamente ogni livello e quale è la scelta giusta a seconda che tu gestisca un singolo sito, un portfolio di agenzia o una configurazione di hosting gestito.

Cosa aggiorna automaticamente WordPress per impostazione predefinita

Per impostazione predefinita, ogni installazione WordPress nel 2026 fa quanto segue senza chiedere:

• Aggiornamenti minori del core. Passare da 6.5.1 a 6.5.2 avviene automaticamente, in background, lo stesso giorno in cui la release viene pubblicata. Queste release sono correzioni di bug e patch di sicurezza. Sono esplicitamente progettate per essere installate in sicurezza senza test.
• Aggiornamenti dei file di traduzione. I pacchetti di lingua vengono aggiornati automaticamente.
• Release di sicurezza del core per branch più vecchi. Anche se il tuo sito è ancora su 6.4 perché non hai eseguito un aggiornamento importante, le correzioni di sicurezza vengono retroportate e applicate automaticamente.

Cosa non avviene automaticamente per impostazione predefinita:

• Aggiornamenti maggiori del core. Passare da 6.5 a 6.6 richiede un clic manuale. WordPress mostra il banner nell'admin ma non lo installa da solo.
• Aggiornamenti di plugin e temi. Entrambi possono essere abilitati per elemento tramite l'UI dell'admin (da WordPress 5.5), ma nessuno è attivo per impostazione predefinita. Sono un argomento separato e non sono controllati da WP_AUTO_UPDATE_CORE.

La ragione di questa divisione è una buona ingegneria: le release minori vengono pubblicate sotto una rigorosa politica di "nessun breaking change", quindi aggiornare silenziosamente è davvero a basso rischio. Le release maggiori occasionalmente introducono nuove API o cambiano comportamenti da cui temi e plugin possono dipendere, e aumentare silenziosamente una versione maggiore in produzione ha storicamente causato abbastanza rotture da indurre il progetto a optare per il predefinito conservativo.

I quattro livelli di aggiornamenti automatici del core

La costante WP_AUTO_UPDATE_CORE in wp-config.php regola tutto questo. Accetta quattro valori:

• true: Tutti gli aggiornamenti del core vengono installati automaticamente, sia minori che maggiori. L'opzione aggressiva.
• 'minor': Il predefinito se la costante non è definita affatto. Solo le release minori e di sicurezza vengono installate automaticamente. Le release maggiori rimangono manuali.
• 'beta' e 'rc': Usate da siti che vogliono build pre-release. Realisticamente solo su un ambiente di staging o test, mai su produzione.
• false: Tutti gli aggiornamenti automatici del core sono disabilitati. Il sito non fa nulla da solo. Sei responsabile per ogni patch, incluse le correzioni di sicurezza.

Impostarne uno è una singola riga in wp-config.php, da qualche parte sopra il commento /* That's all, stop editing! Happy publishing. */:

define('WP_AUTO_UPDATE_CORE', true);

o

define('WP_AUTO_UPDATE_CORE', 'minor');

Salva il file, nessun riavvio necessario. WordPress controlla gli aggiornamenti secondo un programma (predefinito due volte al giorno) e applica ciò che l'impostazione corrente permette.

Quale impostazione ha senso per quale tipo di sito?

La risposta onesta dipende da tre cose: quanto test viene fatto prima che una release vada live, chi se ne accorge quando qualcosa si rompe, e quanto è buona la strategia di backup.

Sito di produzione standard, nessun contratto di manutenzione dedicato

Impostazione raccomandata: true (tutti gli aggiornamenti automatici).

L'intuizione che "gli aggiornamenti automatici maggiori sono pericolosi" è in gran parte superata. Gli aggiornamenti maggiori di WordPress sono stati stabili per anni, e l'alternativa realistica è "nessuno aggiorna il sito per sei mesi perché non c'è un contratto per farlo, e un buco di sicurezza noto rimane aperto". Un sito WordPress non mantenuto è un risultato peggiore del rarissimo aggiornamento automatico che rompe qualcosa. Se una release maggiore rompe il sito, ripristinare da un backup è più veloce del tempo che altrimenti spenderesti a inseguire l'aggiornamento manuale più tardi. L'automazione è la vittoria.

Hosting gestito (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Impostazione raccomandata: quello che fa la dashboard dell'host, di solito 'minor' a livello WordPress.

La maggior parte degli host gestiti esegue il proprio flusso di aggiornamento sopra WordPress. Prima fanno uno snapshot, installano la release maggiore su un clone di staging, eseguono un confronto visivo di base e solo allora la applicano alla produzione. Questo è significativamente più sicuro degli aggiornamenti automatici vanilla. Se sei su questo tipo di host, impostare WP_AUTO_UPDATE_CORE su qualcosa di diverso dal predefinito di solito combatte con la logica dell'host. Lascialo in pace, lascia che l'host faccia il suo lavoro e controlla la dashboard dell'host per la cronologia degli aggiornamenti.

Portfolio di agenzia con un contratto di manutenzione

Impostazione raccomandata: 'minor' in produzione, true in staging.

Se un contratto di manutenzione specifica che testi gli aggiornamenti prima che vadano live, l'agenzia è la rete di sicurezza. La produzione dovrebbe comunque ricevere automaticamente release minori e di sicurezza (queste non sono opzionali dal punto di vista della sicurezza), ma gli aggiornamenti maggiori passano attraverso il flusso di test dell'agenzia. Gli ambienti di staging sono il posto giusto per impostare il valore più aggressivo, in modo che i tester rilevino le rotture presto.

Build WordPress personalizzata con pesanti personalizzazioni di tema o plugin

Impostazione raccomandata: 'minor', più un vero processo di test per gli aggiornamenti maggiori.

I siti che sono pesantemente personalizzati (header ricostruito, blocchi Gutenberg personalizzati, integrazioni di page builder strane, endpoint REST personalizzati) sono esattamente il caso in cui un aggiornamento maggiore può rompere qualcosa di sottile. L'impostazione predefinita 'minor' è il limite inferiore giusto: non rinunciare alle patch di sicurezza, ma tratta le release maggiori come un compito separato con un vero round di test.

Sito ad alta disponibilità che assolutamente non può rompersi

Impostazione raccomandata: false per il core, più un vero processo di release.

Questo è l'unico caso in cui disabilitare completamente gli aggiornamenti automatici del core ha senso. Banche, sanità, ambienti regolamentati dove ogni modifica passa attraverso un processo di release. Nota che accetti la piena responsabilità per applicare manualmente le patch di sicurezza entro ore da una release, su ogni sito. La maggior parte dei team che scelgono questa impostazione ha anche il monitoraggio sulla mailing list di sicurezza WordPress e una pipeline di deployment che può inviare patch lo stesso giorno.

Come verificare che la tua impostazione sia attiva

1. Nell'admin di WordPress, vai a Strumenti, Salute del sito, Info.
2. Espandi la sezione Costanti WordPress.
3. Cerca WP_AUTO_UPDATE_CORE. Se mostra il tuo valore, la costante viene letta.
4. Per un controllo più approfondito, guarda Aggiornamenti nella sidebar dell'admin. Gli aggiornamenti automatici recenti appaiono lì con i timestamp.

Se il valore della costante non appare in Salute del sito, la causa più probabile è che è stata impostata più tardi dopo che il file l'aveva già definita prima (il primo define vince, e PHP genera una notifica che potresti non vedere), o che hai modificato il wp-config.php sbagliato.

Cosa può andare storto con gli aggiornamenti automatici del core

Tre modalità di guasto sono realistiche e vale la pena conoscere:

• L'aggiornamento fallisce parzialmente. Il download o l'estrazione si rompe a metà strada, spesso perché l'host non ha abbastanza spazio su disco, ha raggiunto un limite di inode o per un problema di rete temporaneo. WordPress lascia un file .maintenance nella root e il sito mostra per sempre "Temporaneamente non disponibile per manutenzione programmata". Soluzione: SFTP nella root ed elimina il file .maintenance, poi esegui di nuovo l'aggiornamento dall'admin.
• L'aggiornamento ha successo ma un plugin inizia a generare errori. Specialmente dopo un aggiornamento maggiore, un plugin non mantenuto può rompersi contro le nuove API del core. Soluzione: assicurati di avere un backup, identifica il plugin rotto dal log degli errori (o disattivando i plugin uno per uno) e aggiorna o sostituisci il plugin.
• L'aggiornamento viene saltato silenziosamente. Ragioni comuni: DISALLOW_FILE_MODS è impostato in wp-config.php (che blocca tutti gli aggiornamenti, automatici o no), i permessi sui file sulla cartella WordPress impediscono a PHP di scrivere, o il sito usa Git per il controllo versione e WordPress rileva la cartella .git e disabilita gli aggiornamenti come misura di sicurezza. La pagina Salute del sito di solito segnala questi casi.

Aggiornamenti automatici e DISALLOW_FILE_MODS

Le due costanti interagiscono in un modo che sorprende le persone. DISALLOW_FILE_MODS (trattato nella nostra knowledge base sotto l'argomento editor di file) blocca tutte le modifiche ai file dal lato WordPress, inclusi gli aggiornamenti automatici del core. Se entrambe le costanti sono impostate:

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

Il risultato è che DISALLOW_FILE_MODS vince. WordPress non aggiornerà nulla automaticamente. Questo raramente è quello che le persone intendono. O vuoi un sito schermato che viene aggiornato dall'esterno (pipeline di deploy, WP CLI), nel qual caso DISALLOW_FILE_MODS = true è giusto e WP_AUTO_UPDATE_CORE è irrilevante. O vuoi che il sito si aggiorni da solo, nel qual caso DISALLOW_FILE_MODS non dovrebbe essere impostato.

E gli aggiornamenti automatici di plugin e temi?

Gli aggiornamenti automatici di plugin e temi sono un meccanismo separato atterrato in WordPress 5.5. Vengono configurati per elemento nell'admin (lista Plugin, il link "Abilita aggiornamenti automatici" in ogni riga) o globalmente tramite filtri. La raccomandazione generale: abilita gli aggiornamenti automatici per ogni plugin di cui ti fidi della disciplina di release del manutentore, lasciali disattivati per i plugin che rilasciano regolarmente breaking change. Specialmente le release maggiori di WooCommerce spesso vale la pena trattenere per un aggiornamento manuale con un rapido test.

Se vuoi abilitare programmaticamente gli aggiornamenti automatici dei plugin per ogni plugin, questo filtro lo fa:

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Metti quello in un piccolo plugin must-use sotto wp-content/mu-plugins/ invece che in functions.php, in modo che un cambio di tema non lo disabiliti.

La conclusione per gli aggiornamenti del core: per la maggior parte dei siti nel 2026, l'impostazione predefinita 'minor' è conservativa nella direzione sbagliata. Imposta WP_AUTO_UPDATE_CORE su true e lascia che la piattaforma si mantenga aggiornata, o impegnati in un vero processo di manutenzione che gestisca manualmente le release maggiori entro un tempo ragionevole. La via di mezzo di "impostazioni predefinite più nessuno controlla" è ciò che produce siti WordPress non protetti che sono indietro di due versioni, e quello è il vero stato ad alto rischio.