Il caso che mi ha convinto è di un anno fa. Un sito di un professionista, hosting affidabile, PHP 7.4 da quattro anni. Il motivo del congelamento era legittimo: un plugin di fatturazione comprato anni prima che non girava su 8.x, e il titolare — ragionevolmente — non voleva rischiare di bloccare le fatture per una "mitiglioria". Tuttoစစ۶ ok, finché una routine di controllo non mi ha fatto notare il dettaglio sgradevole: quel PHP 7.4 non riceveva correzioni di sicurezza da tempo, e due plugin sul sito avevano aggiornamenti che richiedevano 8.x. Il sito non era lento. Era indifeso, con in più una porta aperta che nessuno stava guardando.

Un episodio recente del podcast WP Tavern — il numero 225, con lo sviluppatore Milan Petrović — mette a fuoco esattamente questo: i rischi di sicurezza del PHP legacy in WordPress e perché l'aggiornamento è una questione di sicurezza prima ancora che di performance. In questa guida lo rileggo con la mia ottica di consulente: cosa cambia davvero tra le versioni, come capire dove sei, cosa fare se non puoi aggiornare oggi, e la pipeline per farlo domani senza rompere nulla.

Perché il PHP vecchio è un problema di sicurezza, non solo di velocità

Il punto che l'episodio di WP Tavern aiuta a chiarire è il meccanismo con cui una versione PHP diventa un rischio. Non è che "il vecchio è bucato e il nuovo no": è che ogni ramo di PHP riceve correzioni di sicurezza solo fino alla propria fine del supporto. Da lì in poi, ogni nuova vulnerabilità scoperta nel linguaggio — e ne vengono scoperte — resta aperta per sempre su quel ramo.

PHP 8.1, per fare l'esempio più importante di questo periodo, ha terminato il supporto di sicurezza il 31 dicembre 2025. PHP 8.2 lo chiuderà il 31 dicembre 2026. Le versioni 8.3, 8.4 e 8.5 sono attive. Chi oggi gestisce un sito su 8.0 o 8.1 non sta "risparmiando tempo": sta usando un runtime che non riceverà più correzioni, e ogni mese che passa il divario si allarga.

Il secondo meccanismo è sottile ma contano tanto: le deprecazioni. Le versioni nuove di PHP eliminano funzioni e comportamenti che le vecchie permettevano. Un tema o un plugin scritto per PHP 5.6 o 7.x usa costrutti che le versioni moderne hanno rimosso proprio perché pericolosi o fragili. Aggiornare il PHP senza aggiornare il codice fa saltare il sito; non aggiornare mai significa congelare il codice in un'era in cui i suoi difetti non vengono più corretti. È una trappola a doppia via d'uscita, e l'episodio di WP Tavern descrive bene anche l'effetto collaterale: gli hosting si tengono runtime vecchi vivi solo per non rompere i siti dei clienti, e quel vecchio runtime diventa il rifugio di tutto il software che nessuno vuole più toccare.

E c'è un terzo punto, quello che per me è decisivo nel lavoro di assistenza WordPress: il PHP vecchio limita l'ecosistema. I plugin di sicurezza moderni, i tool di hardening, gran parte delle protezioni che oggi danno vantaggio concreto — tutti preferiscono, e spesso richiedono, versioni PHP aggiornate. Sul sito del mio cliente su 7.4, il miglior plugin di sicurezza dell'anno consigliava "aggiornare PHP" come prima raccomandazione. Il prepared statement più efficace non è dentro un plugin: è il linguaggio stesso.

Dove sei adesso: la mappa delle versioni

Prima di fare piani serve un dato di partenza, e sorprendentemente molti non lo hanno. La versione PHP che gira sul tuo sito non è quella che hai installato tu nel pannello: è quella che l'hosting sta eseguendo in quel momento. Il modo più rapido per vederla è la salute del sito nella dashboard WordPress (Strumenti → Salute del sito) o, da terminale:

# comando WordPress
wp cli info --allow-root

La mappa di riferimento per decidere è quella delle versioni supportate su php.net: ogni ramo mostra le date di fine supporto attivo e di fine supporto di sicurezza. Le scadenze che contano per il tuo piano: 8.1 è già oltre la fine del supporto di sicurezza (dicembre 2025), 8.2 chiude a dicembre 2026. Se il tuo sito è su 7.4 o 8.0, non stai parlando di "aggiornare prima o poi": stai gestendo un debito con scadenza già passata.

Le statistiche ufficiali di wordpress.org sulle versioni PHP in uso mostrano ancora una coda significativa di siti su rami vecchi. È il capitolo che l'episodio di WP Tavern racconta meglio: il supporto di WordPress a versioni PHP molto datate — per anni il minimo ufficiale è rimasto ancorato a un PHP 7.2 — ha dato comodità a migliaia di siti, ma ha anche permesso a quella coda di esistere. La raccomandazione che do ai miei clienti è semplice: se il tuo sito è in quella coda, sei nella parte dell'ecosistema più bersagliata dagli scanner automatici, perché è lì che le vulnerabilità note restano aperte più a lungo.

Non puoi aggiornare oggi? Le mitigazioni che contano

La situazione del mio cliente con il plugin di fatturazione è la più comune: non puoi aggiornare subito, ma non puoi nemmeno lasciare tutto com'è. Ecco le mitigazioni che applico in ordine di efficacia, e che trovi anche nella routine di assistenza WordPress che seguiamo sui siti in gestione.

Aggiorna tutto il resto, subito

Se il runtime è congelato, il codice sopra il runtime non deve esserlo. Plugin e temi aggiornati portano le loro correzioni di sicurezza, indipendenti dalla versione PHP. Il conto alla rovescia qui è semplice: ogni aggiornamento rimandato è una CVE pubblica che chiunque può leggere e sfruttare. Sul sito del cliente, questa fase da sola ha chiuso due falle reali — aggiornamenti disponibili da mesi che nessuno aveva mai installato.

Elimina ciò che è morto

Il secondo passo è un audit di dismissione. Plugin disattivati ma presenti, temi alternativi rimasti lì "per il caso mai", componenti che non si aggiornano da oltre un anno. Ognuno è codice che gira o può essere fatto girare sul tuo vecchio PHP, senza fix. La lista dei plugin WordPress da evitare nel 2026 è un buon punto di partenza per il confronto. Sul sito del cliente abbiamo rimosso undici componenti; il sito non è cambiato di una virgola, la superficie d'attacco sì.

Riduci la superficie e monitora

Finché il vecchio PHP resta, riduci ciò che ci gira attorno: meno utenti amministratori del necessario, accessi protetti da 2FA, WAF attivo con regole aggiornate, log controllati con frequenza. E backup testati, non semplicemente eseguiti: un backup mai ripristinato in prova non è una strategia, è un documento di intenti. La procedura di ripristino di un WordPress hackerato parte sempre da qui: senza backup verificato, ogni scenario peggiora.

La pipeline per aggiornare senza rompere

Veniamo alla parte che molti rimandano perché temono di rompere il sito. La pipeline che uso è in sei passi, e l'ordine conta quanto i passi.

Primo: backup completo verificato, database e file, con un ripristino di prova in staging. Secondo: ambiente di staging sulla stessa versione PHP di destinazione, dove il sito viene clonato e testato così com'è. Terzo: analisi statica del codice con PHPCompatibilityWP, che mappa esattamente quali componenti contengono costrutti incompatibili con la versione di destinazione, così sai dove metterti prima che lo scopra la pagina bianca. Quarto: aggiornamento di plugin e temi PRIMA dello switch PHP, con la versione di destinazione in staging: è l'errore che ho commesso una volta sola nella vita — aggiornare PHP prima dei componenti — e che mi è costato una notte di ripristino. Quinto: switch della versione e test funzionali mirati, le pagine che vendono o raccolgono dati prima delle altre. Sesto: piano di rollback documentato, con tempi e responsabilità scritti prima dell'operazione, non dopo.

Chi preferisce delegare l'intera sequenza trova la stessa pipeline nella pagina del servizio di supporto WordPress: è il lavoro che facciamo ogni settimana, con la differenza che dopo centinaia di esecuzioni le sorprese sono poche e classificate. Per il dettaglio operativo dell'ultima tappa — PHP 8.5 — c'è la guida dedicata a PHP 8.5 e WordPress, con le scadenze di supporto e le prestazioni misurate.

Il costo di non farlo

Chiudo con il conto, perché è lì che la decisione diventa semplice. Un aggiornamento PHP seguito con la pipeline che ho descritto si misura in ore: per un sito ordinario parliamo di una mezza giornata di lavoro, tra staging, analisi, switch e test. L'alternativa — il sito che resta su un ramo senza fix — non ha un costo immediato, e questo è il tranello: per mesi non succede nulla. Poi arriva la CVE sul runtime, o sul plugin che non potevi aggiornare, e i tempi cambiano di scala: ripristino da backup, analisi forense, giorni di sito fermo, e nella peggiore delle ipotesi il rebuild di una parte dell'infrastruttura. Il sito del mio cliente su PHP 7.4 ha fatto la pipeline in una mattina, plugin di fatturazione compreso (il fornitore, dopo tre anni, aveva una versione compatibile che nessuno aveva mai segnalato). Una mattina contro il rischio di una settimana di buco nero: è la matematica più onesta che posso offrire.

E il beneficio invisibile resta: un PHP aggiornato è più veloce, e su un sito moderno la velocità non è estetica — l'analisi delle 12 cause di un sito WordPress lento parte proprio da qui — è la differenza tra thread PHP liberi di servire i clienti e thread bruciati dai bot, come abbiamo visto nei problemi di esaurimento thread dei bot AI. Il vecchio runtime non solo difende pegg: serve pegg.

Riferimenti utili

• WP Tavern #225: i rischi del PHP legacy in WordPress
• Le versioni PHP supportate (php.net)
• Statistiche ufficiali WordPress sulle versioni in uso
• PHP 8.5 e WordPress: come aggiornare senza rischi nel 2026
• Manutenzione WordPress: la routine mensile che evita i disastri