Molte aziende hanno affrontato la migrazione da PHP 7 a PHP 8 tra il 2021 e il 2023, spesso con fatica: codice da adeguare, librerie da aggiornare, test da rifare. Alla fine il progetto si è chiuso con un senso di sollievo e la sensazione di aver risolto il problema per parecchi anni. A settembre 2026 quelle stesse applicazioni, se sono rimaste su PHP 8.0 o 8.1, girano di nuovo su un ramo senza correzioni ufficiali.
In questo articolo vediamo quando e perché i due rami sono usciti dal supporto, chi corregge ancora i loro pacchetti, cosa rischia chi è rimasto e perché la buona notizia è che il passo successivo è molto più corto del salto da PHP 7. Chiudiamo con un metodo pratico per misurare il lavoro a partire dai log di deprecazione.
Due rami moderni, già chiusi
PHP 8.0, rilasciato il 26 novembre 2020, ha portato il compilatore JIT, gli argomenti con nome, i tipi unione, l’espressione match, l’operatore nullsafe ?->, gli attributi e la promozione delle proprietà nel costruttore. PHP 8.1, rilasciato il 25 novembre 2021, ha aggiunto le enumerazioni, le proprietà in sola lettura, le fiber e i tipi intersezione. È stato anche il primo ramo a supportare ufficialmente OpenSSL 3, la serie usata dalle distribuzioni Linux recenti.
Sono funzionalità che si usano ancora oggi e che rendono il codice di quegli anni indistinguibile, a prima vista, da quello scritto per i rami attuali. Il ciclo di vita, però, non guarda alla modernità del linguaggio, perché ogni ramo ha una data di scadenza fissata dal giorno del rilascio, come abbiamo spiegato nell’articolo sul ciclo di vita delle versioni di PHP.
Perché due scadenze così diverse
PHP 8.0 è uscito di scena secondo la regola dell’epoca: due anni di supporto attivo, fino al 26 novembre 2022, e uno di sola sicurezza, fino al 26 novembre 2023. L’ultimo rilascio è stato PHP 8.0.30, nell’agosto 2023.
PHP 8.1 avrebbe dovuto seguire la stessa sorte a novembre 2024. Nell’aprile di quell’anno, però, il progetto ha approvato la riforma del ciclo di rilascio, che ha aggiunto un anno di sicurezza e allineato le scadenze al 31 dicembre. PHP 8.1, che era già in sola sicurezza, ha ricevuto l’anno in più ed è rimasto supportato fino al 31 dicembre 2025. L’ultimo rilascio, PHP 8.1.34, è uscito il 18 dicembre 2025.
Le distribuzioni che li correggono ancora
Come per ogni ramo, conta chi ha costruito il pacchetto installato. Per PHP 8.0 e 8.1 la situazione a settembre 2026 è questa:
- Red Hat Enterprise Linux 9 include PHP 8.0 come versione di sistema, con un ciclo di vita pari a quello di RHEL 9, secondo la tabella del ciclo di vita degli Application Streams. Rocky Linux e AlmaLinux 9 ricostruiscono gli stessi pacchetti. Lo stream PHP 8.1 di RHEL 9, invece, è stato ritirato a maggio 2025;
- Red Hat Enterprise Linux 8 offriva PHP 8.0 come stream aggiuntivo, ritirato a novembre 2024: chi lo usa ancora non riceve correzioni;
- Ubuntu 22.04 distribuisce PHP 8.1, corretto durante il supporto standard fino a maggio 2027 e poi con l’abbonamento Ubuntu Pro;
- Debian non ha mai distribuito questi due rami nelle versioni stabili: Debian 11 usa PHP 7.4, Debian 12 usa PHP 8.2. Un PHP 8.0 o 8.1 su Debian arriva quindi da un repository di terze parti come deb.sury.org, e va verificato se e come riceve ancora correzioni;
- Remi e altri repository: valgono le stesse verifiche, leggendo il changelog del pacchetto installato.
Chi è su RHEL 9 con il PHP 8.0 di sistema, o su Ubuntu 22.04 con il PHP 8.1 della distribuzione, e aggiorna regolarmente i pacchetti, ha quindi davanti un tempo ragionevole per pianificare. Chi ha installato questi rami da un repository esterno per avere una versione più recente di quella della distribuzione è spesso nella situazione opposta: aveva scelto il repository per stare avanti, e ora è rimasto indietro.
Cosa rischia chi è rimasto
Sul fronte della sicurezza vale lo stesso discorso di ogni ramo in End of Life: le vulnerabilità corrette nei rami supportati dopo la fine del supporto restano aperte sui pacchetti non mantenuti, e ogni nuovo avviso di sicurezza richiede una valutazione manuale. Con un ramo così vicino a quelli attuali, il codice condiviso è molto e le correzioni pubblicate sono, di fatto, una mappa per chi cerca bersagli.
Sul fronte dell’ecosistema la pressione è forte, perché le applicazioni su PHP 8.0 e 8.1 sono di solito ancora in sviluppo attivo. Laravel 11 e 12 richiedono almeno PHP 8.2, Laravel 13 almeno PHP 8.3; Symfony 7 richiede PHP 8.2 e Symfony 8 PHP 8.4; Drupal 11 non supporta più PHP 8.1 e 8.2; WordPress raccomanda PHP 8.3 o superiore. Restare su 8.0 o 8.1 significa, presto o tardi, non poter installare una versione supportata del proprio framework o CMS, con le relative correzioni di sicurezza.
La buona notizia: il salto è più corto
Chi ha già portato il codice su PHP 8 ha superato la parte più difficile, cioè le rimozioni e i cambi di comportamento della versione principale. Da PHP 8.0 o 8.1 ai rami attuali si sale una serie di gradini più bassi, fatti soprattutto di deprecazioni: avvisi che non bloccano l’esecuzione ma segnalano cosa verrà rimosso in futuro.
Ci sono però alcuni punti da controllare con attenzione:
- le proprietà dinamiche, deprecate in PHP 8.2, sono molto diffuse nel codice applicativo e nei plugin più vecchi: ogni classe che assegna proprietà non dichiarate va corretta o marcata esplicitamente;
- il passaggio di
nullalle funzioni interne, deprecato in PHP 8.1, genera spesso migliaia di avvisi nei log, perché nasce da valori opzionali letti da form, database o configurazioni; - le estensioni spostate in PECL con PHP 8.4, cioè IMAP, OCI8, PDO_OCI e Pspell, non fanno più parte della distribuzione standard: un’applicazione che legge la posta con le funzioni
imap_*o si collega a Oracle ha bisogno di un pacchetto aggiuntivo, o di una libreria alternativa; - le librerie di sistema: PHP 8.4 richiede almeno OpenSSL 1.1.1, libxml2 2.9.4 e libcurl 7.61.0, un dettaglio che conta se si compila su un sistema operativo datato.
Misurare il lavoro con i log di deprecazione
Il modo più concreto per stimare la migrazione è far girare l’applicazione sulla versione di destinazione in un ambiente di prova, con tutte le segnalazioni attive, e contare cosa compare nei log. In un pool di PHP-FPM dedicato ai test bastano tre righe:
; Pool di PHP-FPM dell'ambiente di prova: registra anche le deprecazioni
php_admin_value[error_reporting] = E_ALL
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php-fpm/prova-errori.logDopo aver percorso le funzioni principali dell’applicazione, a mano o con i test automatici, un comando raggruppa gli avvisi per tipo e li ordina per frequenza:
# Deprecazioni raggruppate per messaggio, le più frequenti in cima
grep 'PHP Deprecated' /var/log/php-fpm/prova-errori.log \
| sed -E 's/.*PHP Deprecated: +//; s/ in \/.* on line [0-9]+$//' \
| sort | uniq -c | sort -rn | head -n 20Il risultato è una lista di lavoro concreta: poche voci molto frequenti, di solito risolvibili con interventi mirati, e una coda di casi isolati. Insieme agli errori veri, quelli che interrompono l’esecuzione, e a un’analisi statica con strumenti come PHPStan, dà una stima affidabile del lavoro.
Quale ramo scegliere e come procedere
Da PHP 8.0 o 8.1 conviene puntare almeno a PHP 8.4, supportato fino alla fine del 2028, o a PHP 8.5, supportato fino alla fine del 2029, se framework, CMS e librerie lo permettono. Fermarsi a PHP 8.2 non ha senso, perché esce dal supporto il 31 dicembre 2026: ne parliamo nell’articolo su come prepararsi alla fine del supporto di PHP 8.2. Il percorso è quello di ogni migrazione ben fatta:
- verificare le versioni di PHP supportate da framework, CMS, plugin e librerie, e pianificare i loro aggiornamenti;
- preparare l’ambiente di prova con la versione di destinazione e i log di deprecazione attivi;
- correggere errori e deprecazioni, partendo da quelle più frequenti;
- controllare le estensioni richieste, in particolare quelle spostate in PECL con PHP 8.4;
- rilasciare in produzione con un piano di rollback, tenendo pronta la configurazione precedente.
Se la produzione gira su un pacchetto non più mantenuto e la migrazione richiede qualche mese, nel frattempo la si può proteggere con il backport delle patch di sicurezza sul ramo in uso. Se vuoi una valutazione dei tuoi server, scrivici indicando versione di PHP, sistema operativo e origine dei pacchetti.
Tirando le somme
PHP 8.0 è fuori supporto dal 26 novembre 2023, PHP 8.1 dal 31 dicembre 2025 dopo l’anno aggiuntivo concesso dalla riforma del 2024. Sono rami moderni, eppure senza un fornitore che li corregga ogni nuova vulnerabilità resta aperta e l’ecosistema di framework e CMS li ha già lasciati indietro. RHEL 9 continua a correggere il proprio PHP 8.0 e Ubuntu 22.04 il proprio PHP 8.1, mentre le installazioni da repository esterni vanno verificate una per una. Il passo verso PHP 8.4 o 8.5 è molto più corto del salto da PHP 7: si misura con i log di deprecazione in un ambiente di prova, si affronta partendo dagli avvisi più frequenti e richiede attenzione soprattutto alle estensioni spostate in PECL con PHP 8.4.
