Migrare un'applicazione da PHP 7 a PHP 8: cosa cambia e come farlo senza rischi

Perché aggiornare adesso

PHP 7.4, l'ultima versione della serie 7, ha smesso di ricevere aggiornamenti di sicurezza il 28 novembre 2022. Da allora ogni vulnerabilità scoperta resta aperta. Le conseguenze pratiche sono tre:

• Sicurezza: un'applicazione su una versione non supportata è un bersaglio più facile, e con dati di clienti e dipendenti entra in gioco anche il GDPR.
• Hosting: i provider rimuovono progressivamente le versioni obsolete. Chi non aggiorna si ritrova costretto a farlo in fretta, spesso nel momento peggiore.
• Librerie: le nuove versioni di framework e pacchetti richiedono PHP 8. Restare indietro blocca anche correzioni e nuove funzionalità.

C'è anche un vantaggio concreto: PHP 8 è in generale più veloce della serie 7 e introduce strumenti che rendono il codice più sicuro e leggibile.

Quale versione di PHP 8 scegliere

Non ha senso fermarsi a PHP 8.0 o 8.1, che sono già fuori supporto. Lo stato delle versioni (fonte: php.net):

Per una migrazione fatta oggi l'obiettivo sensato è PHP 8.4, ormai disponibile su tutti i principali hosting, oppure 8.5 se l'hosting e le librerie che usi lo supportano già.

Cosa si rompe più spesso passando a PHP 8

La maggior parte del codice PHP 7 funziona anche su PHP 8, ma alcune modifiche incompatibili emergono quasi sempre. Queste sono le più frequenti nei progetti reali.

Gli errori diventano eccezioni

Molte situazioni che in PHP 7 producevano solo un avviso ora bloccano l'esecuzione con un TypeError o un ValueError: ad esempio passare un tipo sbagliato a una funzione interna, fare operazioni aritmetiche su array o null, dividere per zero (DivisionByZeroError). Codice che “funzionava per caso” smette di funzionare.

Confronti tra numeri e stringhe

Con PHP 8 il confronto non stretto tra un numero e una stringa non numerica confronta i valori come stringhe. Il risultato cambia in casi come questo:

var_dump(0 == "abc");  // PHP 7: true  -  PHP 8: false

È una modifica che rende il linguaggio più sensato, ma può alterare in silenzio la logica di controlli, filtri e validazioni scritti con ==.

Funzioni e sintassi rimosse

• each() e create_function() non esistono più: vanno sostituite con foreach e funzioni anonime.
• L'accesso ai caratteri con le parentesi graffe, $stringa{0}, genera un errore fatale: si usa $stringa[0].
• Gli operatori ternari annidati senza parentesi non sono più ammessi.
• Le connessioni cURL, le immagini GD e altre risorse sono diventate oggetti: i controlli con is_resource() vanno rivisti.

Avvisi più severi su variabili e indici

Leggere una variabile non definita, un indice di array inesistente o una proprietà di null genera ora un warning invece di una semplice notice. Nei log di applicazioni datate compaiono così migliaia di segnalazioni: non bloccano il funzionamento, ma vanno sistemate perché nascondono bug veri.

Le deprecazioni delle versioni 8.1 – 8.4

Se l'obiettivo è PHP 8.4 vanno considerate anche le modifiche delle versioni intermedie, che oggi sono avvisi ma diventeranno errori:

• 8.1: passare null a parametri di funzioni interne che non lo accettano (il classico strlen(null) o trim(null)) è deprecato. È di gran lunga l'avviso più diffuso nei progetti datati.
• 8.2: le proprietà dinamiche, cioè create al volo su oggetti di classi che non le dichiarano, sono deprecate; deprecata anche l'interpolazione "${variabile}".
• 8.4: i parametri con tipo resi implicitamente nullable da un default null (function f(Cliente $c = null)) vanno dichiarati in modo esplicito, ad esempio ?Cliente $c = null.

Le dipendenze

Spesso il blocco non è nel tuo codice ma nelle librerie: versioni vecchie di framework, generatori di PDF, SDK di pagamento. Con Composer il comando composer why-not php 8.4 mostra quali pacchetti impediscono l'aggiornamento. Su progetti senza Composer, con librerie copiate a mano, la verifica va fatta pacchetto per pacchetto.

Un metodo di migrazione in 6 passi

1. Inventario. Versione attuale di PHP, estensioni usate, librerie, cron, integrazioni esterne. Senza una fotografia iniziale non si stima nulla.
2. Messa in sicurezza. Backup completo di codice e database, codice sotto controllo di versione con Git e un ambiente di test separato dalla produzione, con la nuova versione di PHP.
3. Analisi statica. Strumenti come PHPCompatibility (per PHP_CodeSniffer) e PHPStan individuano automaticamente gran parte dei punti incompatibili senza eseguire il codice.
4. Correzioni assistite. Rector applica in automatico molte trasformazioni ripetitive. Ogni modifica va comunque riletta: l'automatismo accelera, non sostituisce la revisione.
5. Test sui flussi reali. Si provano i percorsi che contano per l'azienda: login, inserimento ordini, generazione documenti, pagamenti, invii email, import ed export. Dove possibile si aggiungono test automatici sulle parti critiche.
6. Rilascio con piano di ritorno. Molti hosting permettono di scegliere la versione di PHP per singolo sito: si cambia versione in un momento di basso traffico, si monitorano i log e, in caso di problemi, si torna indietro in pochi minuti.

Quanto tempo serve

Dipende soprattutto da tre fattori: la versione di partenza (da PHP 7.4 il salto è molto più semplice che da PHP 5), la qualità del codice e la presenza di un framework aggiornabile. Un sito aziendale ordinato può richiedere pochi giorni; un gestionale cresciuto per anni senza regole, con librerie abbandonate, richiede un lavoro più lungo da pianificare per fasi.

Serve riscrivere tutto da zero?

Quasi mai. Riscrivere un'applicazione funzionante richiede molto tempo e introduce nuovi bug. Nella maggior parte dei casi conviene un aggiornamento graduale: prima la compatibilità con PHP 8, poi il refactoring delle parti più fragili, mentre il software continua a lavorare.

Mi occupo di questo tipo di interventi da remoto, per aziende in tutta Italia: si parte da un'analisi del codice esistente e da un piano con priorità chiare.