“Funziona, perché toccarlo?” è la frase che tiene in vita migliaia di siti e gestionali su versioni di PHP ormai abbandonate. Ed è una frase comprensibile: l’aggiornamento costa tempo, il sito risponde, i clienti non si lamentano. Il problema è che il rischio di un PHP a fine vita non si vede: non rallenta la pagina, non mostra errori, non manda avvisi. Semplicemente, da un certo giorno in poi, nessuno chiude più le falle che vengono scoperte.

E le falle vengono scoperte comunque. La ricerca di vulnerabilità non si ferma quando finisce il supporto: si ferma solo la distribuzione delle correzioni. Tutto ciò che emerge dopo quella data resta aperto per sempre, su ogni server che esegue quella versione.

Fine del supporto: cosa significa davvero

Ogni versione di PHP attraversa due fasi. Nella prima, il supporto attivo, riceve correzioni di ogni tipo: bug, prestazioni, sicurezza. Nella seconda, il supporto di sicurezza, riceve solo le patch per le vulnerabilità. Finita anche questa, la versione è a fine vita (end of life): il codice continua a girare, ma è ufficialmente abbandonato.

Le date sono pubbliche e non negoziabili: l’intera famiglia PHP 7 è a fine vita dalla fine del 2022, PHP 8.0 dalla fine del 2023 e PHP 8.1 dalla fine del 2025. Nell’estate del 2026 ricevono correzioni solo PHP 8.2 (che chiude a fine anno), 8.3, 8.4 e 8.5. Chi oggi è su PHP 7.4 esegue un software che non vede una patch di sicurezza da quasi quattro anni. Lo stesso meccanismo vale un piano più in basso, per il server che ospita tutto: ne parliamo a proposito di Proxmox VE 8 a fine vita.

I rischi concreti, oltre la teoria

Il primo rischio è ovvio: vulnerabilità senza rimedio. Un sito esposto su internet viene sondato in continuazione da scanner automatici che cercano proprio le installazioni vecchie, perché sono le più facili da bucare. Non serve essere un bersaglio interessante: basta essere raggiungibili.

Il secondo è più sottile: l’ecosistema si sposta. Librerie, framework e piattaforme abbandonano le versioni vecchie di PHP molto prima dei loro utenti: le nuove release di WordPress, PrestaShop, Laravel e delle dipendenze Composer richiedono versioni recenti. Restare fermi su un PHP vecchio significa restare fermi su tutto, moduli di pagamento e plugin di sicurezza inclusi.

Il terzo riguarda chi tratta dati personali: per il GDPR le misure di sicurezza devono essere “adeguate allo stato dell’arte”, e un componente abbandonato dal produttore è difficile da difendere come adeguato, come abbiamo visto parlando di GDPR lato infrastruttura. In caso di violazione, la versione di PHP finisce nel verbale.

L’aggiornamento conviene anche quando non è obbligato

Aggiornare PHP non è solo togliersi un rischio: è uno dei pochi interventi che migliora le prestazioni senza toccare una riga di codice. Ogni release recente esegue lo stesso programma più in fretta della precedente, e su un sito dinamico la differenza si misura, come racconta la nostra guida su come velocizzare un PrestaShop. Meno tempo di CPU per richiesta significa anche server più piccoli a parità di traffico: l’aggiornamento spesso si ripaga in bolletta.

Come si migra senza drammi

La migrazione temuta “perché poi si rompe tutto” si affronta come ogni intervento serio: con un metodo, non con il coraggio.

1. Inventario: quali applicazioni girano, su quale versione, con quali estensioni e dipendenze. Senza questa mappa ogni stima è una scommessa.
2. Prova in un ambiente separato: si replica il sito su un ambiente di test con la versione di destinazione e si guardano log e deprecation warning. Gli strumenti di analisi statica segnalano in anticipo il codice incompatibile.
3. Aggiornamenti graduali: meglio salire una versione alla volta che saltare dal 7.4 all’8.5 in un colpo solo, correggendo le incompatibilità a piccoli passi.
4. Rete di sicurezza: prima di toccare la produzione, un backup verificato e un piano di rientro. Se qualcosa va storto, si torna indietro in minuti, non in nottate.

Per un e-commerce o un gestionale su misura il grosso del lavoro non è quasi mai PHP in sé, ma i moduli e il codice custom scritti anni fa: è lì che serve la mano di chi queste migrazioni le fa di mestiere.

In sintesi

Una versione di PHP a fine vita non smette di funzionare: smette di essere difesa. Le falle nuove restano aperte per sempre, l’ecosistema di librerie e piattaforme si allontana, e la conformità GDPR diventa difficile da sostenere. La migrazione, affrontata con inventario, ambiente di prova, passi graduali e backup, è un progetto ordinario e non un salto nel vuoto; in cambio si ottiene un sito più sicuro, più veloce e di nuovo libero di aggiornare tutto il resto.

Fonti

• Supported Versions - php.net
• PHP - endoflife.date
• OPcache - manuale ufficiale PHP