Aggiornamenti di WordPress: core, temi e plugin, perché non vanno mai ignorati
Rischi del «non tocco niente che funziona», finestra di rilascio patch di sicurezza, pianificazione
«Se funziona, non toccarlo» è una tentazione comprensibile ma pericolosa quando si parla di WordPress. Core, temi e plugin sono migliaia di righe di codice mantenute da persone diverse, con calendari di rilascio diversi: ogni componente riceve aggiornamenti in momenti e per motivi differenti, e ignorarli non congela il sito in uno stato sicuro, esponendolo a grossi rischi.
1. Tre livelli di aggiornamento, tre logiche diverse
- Core versioni minori (es. 6.7 → 6.7.1): correzioni di sicurezza e manutenzione. Si installano da sole in background, per tutti i siti, per impostazione predefinita.
- Core versioni maggiori (es. 6.7 → 6.8): nuove funzionalità. Dalla versione 5.6, anche queste si aggiornano in automatico sulle nuove installazioni, salvo disattivazione esplicita.
- Temi e plugin: restano manuali per impostazione predefinita, a meno che l'amministratore non attivi l'aggiornamento automatico singolarmente per ciascuno.
Fonte: developer.wordpress.org: Advanced Administration Handbook, «Upgrading WordPress»: dalla versione 5.6 le nuove installazioni hanno gli aggiornamenti automatici abilitati sia per le release minori sia per quelle maggiori del core, salvo che WordPress rilevi un checkout da controllo di versione.
2. La finestra tra una patch e il suo sfruttamento
Quando WordPress rilascia una correzione di sicurezza, il codice della patch diventa pubblico insieme al changelog: chiunque può confrontarlo con la versione precedente e capire esattamente quale falla veniva corretta. È il motivo per cui gli aggiornamenti automatici in background, per temi e plugin, scattano anche fuori dal controllo dell'amministratore quando il team di sicurezza di WordPress.org individua una vulnerabilità critica: il rischio più alto non è prima della patch, ma nella finestra subito dopo, quando l'exploit è ormai di dominio pubblico e il tuo sito, se non aggiornato, resta un bersaglio riconoscibile.
3. «Non tocco niente che funziona»: il rischio nascosto
Questo ragionamento confonde «non si vede nulla di rotto» con «è al sicuro». Una vulnerabilità non corretta non produce alcun sintomo visibile finché qualcuno non la sfrutta: il sito continua ad apparire identico fino al giorno in cui smette di esserlo. C'è anche un secondo effetto, meno discusso: più si rimanda un aggiornamento, più cresce la distanza e quindi il rischio di incompatibilità tra la versione installata e quella corrente, rendendo l'aggiornamento futuro, quando sarà inevitabile, molto più delicato di quanto sarebbe oggi.
4. Pianificare invece di reagire
Una gestione ragionata degli aggiornamenti non significa applicarli alla cieca il giorno stesso del rilascio, ma nemmeno rimandarli a data da destinarsi:
- Backup prima di ogni aggiornamento: un salvataggio recente rende reversibile qualunque imprevisto.
- Aggiornamenti di sicurezza del core: lasciarli sempre attivi: sono lo scudo minimo che WordPress stesso considera non negoziabile.
- Plugin critici (pagamenti, form, page builder): testarli su un ambiente di staging prima di aggiornarli in produzione.
- Un controllo pianificato, settimanale o mensile, invece di aspettare che qualcosa smetta di funzionare.
In sintesi
| Cosa aggiornare | Comportamento di default | Buona prassi |
|---|---|---|
| Core versioni minori | Automatico in background | Non disattivarle mai |
| Core versioni maggiori | Automatico dalla 5.6, salvo disattivazione | Testare su staging se il sito è complesso |
| Temi e plugin | Manuali, salvo attivazione singola | Aggiornamento pianificato + backup prima |
Aggiornare non è un'attività da fare «quando c'è tempo»: è la differenza tra un sito che resta protetto e uno che aspetta solo di essere trovato. La pianificazione, backup, staging per i plugin critici, controlli regolari, trasforma un obbligo temuto in una routine che richiede pochi minuti a settimana.
Per approfondire
- Staging: testare le modifiche prima di pubblicarle sul sito live: l'ambiente dove provare gli aggiornamenti prima di farli sul sito live.
- Utenti e ruoli in WordPress: dal Sottoscrittore all'Amministratore: chi ha il permesso di aggiornare, e chi no.
Commenti (0)
Registrati per commentare, fare domande e proporre l'argomento della prossima pillola (oppure accedi se hai già un account).
Nessun commento. Sii il primo a scrivere qualcosa.