PHP 7.4 è uscito dal supporto ufficiale il 28 novembre 2022, quasi quattro anni fa. Per molte aziende però è ancora la versione “normale”: quella su cui gira il sito istituzionale, il negozio online, l’intranet. Non è un ramo antico come il 5.6, il codice è spesso ordinato e moderno, e proprio per questo il passaggio a PHP 8 viene percepito come un aggiornamento qualunque, da fare quando capita. Poi si prova a cambiare versione in un ambiente di test e compaiono errori in punti inattesi.
In questo articolo vediamo perché PHP 7.4 si è diffuso così tanto, chi lo corregge ancora a settembre 2026 e a quali condizioni, cosa rischia chi è rimasto e perché il salto a PHP 8 richiede un progetto vero, anche se piccolo. Chiudiamo con la scelta della versione di destinazione e con i passi per arrivarci senza fermare la produzione.
L’ultimo ramo di PHP 7
PHP 7.4.0 è stato rilasciato il 28 novembre 2019. Ha avuto due anni di supporto attivo, fino a novembre 2021, e un anno di sola sicurezza, secondo la regola dell’epoca; l’ultimo rilascio, 7.4.33, è uscito il 3 novembre 2022. La riforma del ciclo di vita approvata nel 2024, che ha allungato la fase di sicurezza a due anni, è arrivata troppo tardi per lui.
Le ragioni della sua diffusione sono diverse e si sommano:
- era l’ultimo ramo della serie 7: chi doveva aggiornare da PHP 5 o dai primi rami 7 lo ha scelto come punto di arrivo, perché il più recente compatibile con il proprio codice;
- ha portato funzionalità molto usate, come le proprietà tipizzate, le funzioni freccia e l’operatore
??=, che hanno reso il codice più moderno senza le rotture di PHP 8; - è stato la versione predefinita di distribuzioni molto diffuse, come Debian 11 e Ubuntu 20.04, ed è disponibile come stream su Red Hat Enterprise Linux 8 e derivate;
- molte piattaforme lo accettano ancora: WordPress, per esempio, dichiara di funzionare con PHP 7.4, pur raccomandando la 8.3 o superiore e avvertendo che il ramo è in End of Life.
Il risultato è un ramo che si trova ovunque, spesso su server configurati bene e mantenuti con cura, dove l’unico componente fuori supporto è proprio PHP.
Chi corregge ancora PHP 7.4
Il progetto PHP non lo corregge più dal novembre 2022. Sui server Linux, però, PHP arriva quasi sempre dai pacchetti della distribuzione, e alcune distribuzioni continuano a correggere il proprio PHP 7.4 per tutto il loro ciclo di vita. A settembre 2026 il quadro è questo:
- Debian 11 distribuisce PHP 7.4. Il supporto del team di sicurezza è terminato nell’agosto 2024 e quello del progetto Debian LTS il 31 agosto 2026: da questo mese il pacchetto non riceve più correzioni dal progetto Debian;
- Ubuntu 20.04 distribuisce PHP 7.4. Il supporto standard è terminato a maggio 2025; con l’abbonamento Ubuntu Pro gli aggiornamenti di sicurezza proseguono fino a maggio 2030, come indicato nel ciclo di rilascio di Ubuntu;
- Red Hat Enterprise Linux 8 offre PHP 7.4 come stream applicativo con ciclo di vita pari a quello del sistema, che è in fase di manutenzione fino al 2029. In questa fase Red Hat rilascia le correzioni secondo i propri criteri, che privilegiano le vulnerabilità più gravi. Rocky Linux e AlmaLinux 8 ricostruiscono gli stessi pacchetti;
- CentOS 8 non riceve aggiornamenti dalla fine del 2021, quindi nemmeno il suo PHP;
- repository di terze parti come Remi o deb.sury.org: verifica caso per caso se e come il ramo 7.4 riceve ancora correzioni, leggendo il changelog del pacchetto.
Se il tuo PHP 7.4 viene da una di queste fonti ancora attive e lo aggiorni regolarmente, hai tempo per pianificare la migrazione. Se viene da un repository che non lo corregge più, da una compilazione manuale o da un sistema già fuori supporto, sei nella situazione di qualunque ramo in End of Life.
Cosa rischia chi è rimasto
Il primo rischio è la sicurezza. Le vulnerabilità corrette dopo novembre 2022 nei rami 8.x riguardano spesso codice che esisteva già in PHP 7.4, e su un pacchetto non più mantenuto restano aperte. Non tutte si applicano a ogni configurazione: contano la SAPI, le estensioni caricate e l’esposizione del server. Ma l’elenco si allunga a ogni rilascio dei rami supportati.
Il secondo è l’ecosistema, che su PHP 7.4 si muove più in fretta che su PHP 5.6, perché le applicazioni su 7.4 sono di solito ancora vive e aggiornate. Le versioni recenti dei framework non lo supportano più: Laravel 10 richiedeva già PHP 8.1, Laravel 11 e Symfony 7 almeno PHP 8.2. Lo stesso vale per molte librerie installate con Composer, per gli SDK dei servizi di pagamento e per i plugin dei CMS. Prima o poi un aggiornamento necessario, magari una correzione di sicurezza di una libreria, non sarà più installabile su PHP 7.4.
Il terzo è la conformità: scanner di vulnerabilità e auditor segnalano PHP 7.4 come componente fuori supporto, e la risposta deve essere documentata, sia che il pacchetto sia ancora corretto dalla distribuzione sia che non lo sia.
Perché il salto a PHP 8 non è solo un aggiornamento
PHP 8.0 è una versione principale, e come tale ha rimosso funzionalità deprecate da anni e cambiato comportamenti di base del linguaggio. Molte di queste modifiche non producono un errore evidente al primo avvio: si manifestano su un percorso specifico, con dati particolari, a volte solo come risultato diverso.
Le più insidiose, secondo la guida di migrazione ufficiale, sono tre:
- il confronto tra numeri e stringhe: in PHP 7.4
0 == "foo"era vero, in PHP 8 è falso. Un controllo su un parametro o su un valore letto dal database può cambiare esito senza alcun messaggio; - le eccezioni sui tipi: operazioni che prima producevano un avviso, come un calcolo su un array o un
count()su un valore non contabile, ora lanciano unTypeErrore interrompono la pagina; - gli errori non più nascosti: il livello di segnalazione predefinito diventa
E_ALLe l’operatore@non silenzia più gli errori fatali. Codice che “funzionava” ignorando gli errori comincia a mostrarli.
Poi ci sono le deprecazioni dei rami successivi, che non rompono nulla subito ma riempiono i log e indicano il lavoro futuro. La più frequente nel codice nato per PHP 7 è quella introdotta in PHP 8.1 sul passaggio di null ai parametri non nullabili delle funzioni interne, per esempio strlen(null); in PHP 8.2 si aggiungono le proprietà dinamiche, cioè create su un oggetto senza essere dichiarate nella classe.
Quale versione scegliere come destinazione
Uscendo da PHP 7.4 non ha senso fermarsi a PHP 8.0 o 8.1, già fuori supporto, né a PHP 8.2, che chiude il 31 dicembre 2026. Le scelte ragionevoli sono:
| Destinazione | Supporto di sicurezza fino al | Quando sceglierla |
|---|---|---|
| PHP 8.3 | 31 dicembre 2027 | se una dipendenza non è ancora pronta per i rami successivi |
| PHP 8.4 | 31 dicembre 2028 | scelta equilibrata per la maggior parte delle applicazioni |
| PHP 8.5 | 31 dicembre 2029 | se CMS, framework e librerie lo supportano già |
La regola pratica è scegliere il ramo più recente che tutte le componenti dell’applicazione supportano ufficialmente. Il lavoro per passare da 7.4 a 8.3 o a 8.5 è in gran parte lo stesso, perché il grosso delle rotture è nella 8.0, mentre gli anni di supporto guadagnati sono diversi.
Come procedere senza fermare la produzione
Un primo controllo utile è verificare che tutto il codice sia almeno sintatticamente valido per la versione di destinazione. Il controllo di sintassi di PHP 8 intercetta subito, per esempio, l’accesso con parentesi graffe e i cast rimossi:
# Controllo di sintassi con l'interprete di destinazione, mostrando solo i file
# con errori (php8.4 è il nome dell'eseguibile su Debian e Ubuntu)
find /var/www/sito -name '*.php' -not -path '*/vendor/*' \
-exec php8.4 -l {} \; 2>&1 | grep -v '^No syntax errors'La maggior parte dei problemi, però, emerge solo eseguendo il codice. Il percorso che seguiamo nei progetti di migrazione è questo:
- inventario di applicazione, dipendenze Composer, plugin, temi e versioni minime richieste da ciascuno;
- analisi statica con strumenti come PHPStan e lo standard PHPCompatibility per PHP_CodeSniffer, per trovare le incompatibilità note;
- ambiente di prova con la versione di destinazione, i dati reali resi anonimi dove serve e tutti i log di errore e di deprecazione attivi;
- test dei percorsi critici: login, ricerca, carrello, pagamento, esportazioni, cron;
- correzioni e aggiornamenti delle dipendenze, ripetendo i test finché i log sono puliti;
- passaggio in produzione con un piano di rollback, tenendo pronto il pool PHP-FPM della versione precedente.
Nel frattempo la produzione su PHP 7.4 va protetta: con i pacchetti della distribuzione, se ancora mantenuti e aggiornati, oppure con il backport delle patch di sicurezza sul ramo 7.4, che chiude le vulnerabilità note senza toccare l’applicazione mentre la migrazione procede.
Conclusioni
PHP 7.4, l’ultimo ramo della serie 7, è fuori supporto ufficiale dal 28 novembre 2022 ed è ancora molto diffuso, perché è stato la destinazione naturale di tante migrazioni e la versione predefinita di distribuzioni come Debian 11 e Ubuntu 20.04. A settembre 2026 il pacchetto è ancora corretto su Ubuntu 20.04 con Ubuntu Pro e su RHEL 8 e derivate, mentre su Debian 11 il supporto LTS si è appena chiuso. Restarci significa vulnerabilità che si accumulano, un ecosistema che non lo supporta più e domande sempre più precise da parte degli auditor. Il passaggio a PHP 8 cambia confronti, tipi e gestione degli errori, quindi va trattato come un progetto: analisi, test sui percorsi critici e rilascio con rollback, verso PHP 8.4 o 8.5 se le dipendenze lo permettono, proteggendo la produzione nel frattempo.
