Aggiornare PHP Su Wordpress: Piano Prima della Fine di PHP 8.2

Se il tuo sito aziendale gira su WordPress, c’è una data da segnare: il 31 dicembre 2026 PHP 8.2 arriva a fine vita. Da quel giorno non riceverà più patch di sicurezza ufficiali. Il sito continuerà a funzionare, ma ogni vulnerabilità scoperta dopo quella data resterà aperta. La risposta breve alla domanda “come aggiornare PHP su WordPress” è: inventario, copia di staging, test, passaggio controllato in produzione e piano di rollback pronto. Non si cambia la versione dal pannello di venerdì pomeriggio sperando che vada bene.

In questo articolo descrivo il processo che uso sui siti WordPress che sviluppo e gestisco, come lapidari.it e opticagheller.it, ospitati su server con HestiaCP. È pensato per titolari e responsabili di PMI che vogliono capire cosa chiedere al proprio fornitore, o cosa fare se il sito lo gestiscono internamente.

Perché la versione di PHP conta per un sito aziendale

PHP è il linguaggio che esegue WordPress, il tema e tutti i plugin. Ogni versione ha un ciclo di vita: due anni di supporto attivo e poi un periodo di sole correzioni di sicurezza. Per PHP 8.2 quel periodo termina a fine 2026, come riportano sia ThriveWP sia l’analisi di G-Unit Solutions. WordPress oggi raccomanda PHP 8.3 o superiore.

Restare su una versione non supportata ha tre conseguenze concrete:

Sicurezza: le falle nel motore PHP non vengono più corrette dal progetto ufficiale.
Compatibilità: gli sviluppatori di plugin, col tempo, smettono di testare sulle versioni vecchie. Un aggiornamento di plugin può rompere il sito proprio perché sei rimasto indietro.
Responsabilità: se il sito tratta dati personali (moduli contatto, area riservata, e-commerce), il GDPR chiede misure tecniche adeguate. Software senza patch è difficile da difendere come “adeguato”.

L’aggiornamento di PHP è solo un tassello della sicurezza: hardening, backup e aggiornamenti regolari restano la base, come spiego nella guida su WordPress sicuro per aziende.

PHP 8.3 o PHP 8.4: quale scegliere

Oggi le opzioni sensate sono due. PHP 8.3 ha supporto di sicurezza fino a fine 2027, PHP 8.4 fino a fine 2028. La mia regola pratica:

PHP 8.4 se tema e plugin sono aggiornati e mantenuti: guadagni un anno in più prima del prossimo intervento.
PHP 8.3 se il sito usa plugin datati, un tema personalizzato scritto anni fa o codice di terze parti che non puoi modificare subito. È il passaggio più morbido da 8.2.

La decisione non si prende a tavolino: si prende dopo i test in staging, che mostrano cosa funziona davvero.

Il piano operativo, mese per mese

Con la scadenza al 31 dicembre, la tempistica che propongo è questa:

Ottobre: inventario. Per ogni sito si raccolgono versione PHP attuale, versione di WordPress, elenco plugin con data dell’ultimo aggiornamento, tema (standard, child theme o su misura) ed eventuale codice personalizzato.
Novembre: staging e test. Copia completa del sito su un ambiente separato con la nuova versione di PHP, test funzionali e correzioni.
Inizio dicembre: passaggio in produzione. Prima delle festività, quando chi deve verificare è ancora in ufficio.

Per un e-commerce aggiungo un vincolo: niente modifiche infrastrutturali nella settimana del Black Friday. In quel caso il test va chiuso entro metà novembre oppure lo switch slitta alla prima settimana di dicembre.

Cosa guardare nell’inventario

Plugin non aggiornati da oltre un anno o rimossi dal repository ufficiale: sono i primi candidati a dare problemi.
Plugin premium con licenza scaduta: spesso girano su versioni vecchie perché nessuno ha rinnovato.
Snippet aggiunti nel functions.php o plugin “fatti in casa”.
Estensioni PHP necessarie (ad esempio imagick, intl, gd, zip): devono essere installate anche per la nuova versione.

Staging e test: dove si trovano i problemi

Lo staging è una copia del sito, con database e file, su un sottodominio non indicizzato e protetto da password. Lì attivo la nuova versione di PHP e procedo in quest’ordine:

Analisi statica del codice di tema e plugin con PHP_CodeSniffer e le regole PHPCompatibility, che segnalano funzioni rimosse o deprecate nella versione di destinazione.
Log degli errori attivi (WP_DEBUG_LOG in staging, mai visibile ai visitatori) per catturare warning e deprecation durante la navigazione.
Test funzionali manuali dei percorsi che contano per l’azienda: invio dei moduli, prenotazioni, area riservata, checkout, ricerca, pannello di amministrazione.
Test delle attività pianificate: cron di WordPress, email automatiche, sincronizzazioni, esportazioni.

I problemi più comuni non sono crash evidenti, ma comportamenti silenziosi: un modulo che non invia più l’email, un’immagine che non viene ridimensionata perché manca un’estensione, un plugin che registra centinaia di avvisi di deprecazione e riempie il disco. Ad esempio, PHP 8.4 depreca i parametri implicitamente nullable, una forma molto usata nel codice scritto anni fa. Non rompe nulla oggi, ma va sistemata prima che diventi un errore nelle versioni successive.

Se un plugin è incompatibile le strade sono tre: aggiornarlo, sostituirlo con un’alternativa mantenuta, oppure correggere il codice quando si tratta di sviluppo su misura. Sui temi WordPress che scrivo io, la correzione è parte della manutenzione.

Il passaggio in produzione con HestiaCP

HestiaCP supporta più versioni di PHP sullo stesso server tramite PHP-FPM: ogni dominio ha il proprio template di backend e può usare una versione diversa. Questo è fondamentale, perché permette di migrare un sito alla volta invece di aggiornare tutto il server in un colpo. Ho descritto l’impostazione generale in come gestisco l’hosting dei clienti con HestiaCP.

La sequenza in produzione è breve e ripetibile:

Backup completo di file e database, verificato e non solo “lanciato”.
Controllo che le estensioni PHP necessarie siano installate per la nuova versione.
Cambio del template PHP-FPM del dominio dalla versione 8.2 alla 8.3 o 8.4.
Svuotamento delle cache (plugin di cache, OPcache, eventuale CDN).
Ripetizione dei test funzionali essenziali sul sito pubblico e monitoraggio dei log nelle ore successive.

Il cambio di versione in sé richiede pochi secondi e non comporta un vero fermo del sito.

Il rollback: decidere prima quando tornare indietro

Il piano di rollback va scritto prima dello switch, non durante l’emergenza. Nella maggior parte dei casi basta riportare il template del dominio alla versione precedente: è un’operazione immediata. Se nel frattempo sono stati aggiornati anche plugin o database, serve il backup appena fatto. Per questo raccomando di non combinare l’aggiornamento di PHP con altri aggiornamenti importanti nella stessa finestra: se qualcosa si rompe, vuoi sapere subito qual è la causa. Su backup e ripristino trovi il dettaglio nell’articolo dedicato a backup e disaster recovery per siti aziendali.

Se non sai chi gestisce il tuo server

Capita spesso: il sito è stato fatto anni fa, l’hosting è condiviso, nessuno ricorda le credenziali del pannello. In questo caso il primo passo è semplice:

Verifica la versione PHP in uso da Strumenti → Salute del sito → Info → Server nel pannello di WordPress.
Chiedi al provider di hosting quali versioni offre e se intende disattivare la 8.2.
Recupera l’accesso al pannello di hosting e al dominio: senza quelli ogni intervento diventa più lento e rischioso.

Alcuni hosting condivisi aggiornano la versione PHP d’ufficio. Se succede senza un test preventivo, il sito può smettere di funzionare da un giorno all’altro. Meglio arrivarci con un piano.

Domande frequenti

Se resto su PHP 8.2 dopo il 31 dicembre il sito smette di funzionare?

No, il sito continua a funzionare. Il problema è che eventuali nuove vulnerabilità di PHP 8.2 non verranno più corrette dal progetto ufficiale, e col tempo plugin e temi smetteranno di garantire la compatibilità.

Aggiornare PHP rallenta o velocizza WordPress?

Le versioni recenti di PHP sono in genere più efficienti, ma il guadagno reale dipende dal sito, dalla cache e dai plugin. Non prometto numeri senza misurarli: il motivo principale per aggiornare è la sicurezza.

Posso aggiornare PHP direttamente dal pannello di hosting?

Tecnicamente sì, ma senza un test in staging e un backup verificato rischi errori su moduli, pagamenti o area riservata, spesso scoperti dai clienti prima che da te.

Quanto tempo richiede l’intervento?

Dipende dal numero di plugin e dalla quantità di codice personalizzato. Un sito con tema e plugin aggiornati si migra in tempi brevi; un sito con componenti abbandonati richiede sostituzioni o correzioni. L’inventario serve proprio a stimarlo prima.

Prepararsi adesso, non a dicembre

Aggiornare PHP su WordPress non è complicato, ma richiede metodo: sapere cosa c’è sul sito, provarlo su una copia, passare in produzione con un’uscita di emergenza pronta. Se hai uno o più siti WordPress aziendali e vuoi arrivare al 31 dicembre senza sorprese, oppure ti serve qualcuno che si occupi di sviluppo, hosting e manutenzione end-to-end, scrivimi dalla pagina contatti: partiamo dall’inventario e decidiamo insieme la versione di destinazione.