Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto

Nei miei vent'anni di consulenza su applicativi PHP per PMI, ho gestito decine di migrazioni da PHP 5 a versioni moderne. L'intervento più critico ha riguardato un gestionale per un'azienda del settore manifatturiero: l'applicativo girava su PHP 5.6 con estensioni mysql_* (rimosse in PHP 7.0), nessun type hint, error handling basato su @ e die(), e dipendenze Composer bloccate a versioni del 2016. Il server Debian su cui girava non riceveva più aggiornamenti di sicurezza dal 2020. La migrazione a PHP 8.3 ha richiesto otto settimane - riscrittura delle query con PDO, introduzione di tipizzazione strict, aggiornamento di tutte le dipendenze - ma i risultati sono stati immediati: tempo di risposta delle pagine ridotto del 40%, eliminazione di tre vulnerabilità SQL injection che esistevano da anni nel codice originale, e accesso all'ecosistema moderno di librerie e framework.

Perché un applicativo su PHP 5 è un rischio concreto per la tua azienda?

PHP 5.6, l'ultima release della serie 5.x, ha raggiunto l'End of Life il 31 dicembre 2018. Da quella data, nessuna vulnerabilità di sicurezza scoperta nel runtime PHP 5 viene corretta. Ma il problema non si ferma qui: l'intera serie PHP 7.x è anch'essa fuori supporto (PHP 7.4, l'ultima della serie, è EOL dal 28 novembre 2022), PHP 8.0 è EOL dal 26 novembre 2023, e PHP 8.1 ha perso il supporto di sicurezza il 31 dicembre 2025. Secondo la pagina ufficiale delle versioni supportate di PHP, solo PHP 8.2 (security-only fino al 31 dicembre 2026), 8.3, 8.4 e 8.5 ricevono attualmente manutenzione.

Questo significa che un applicativo su PHP 5.6 accumula oltre sette anni di vulnerabilità non corrette nel runtime. Ma il rischio non è solo teorico: W3Techs rileva che una percentuale non trascurabile di siti web gira ancora su PHP 5 e 7, e questi siti sono bersagli privilegiati perché le vulnerabilità sono note, documentate e facilmente sfruttabili.

Le conseguenze concrete per una PMI:

• Ogni CVE scoperta in PHP 5.x o 7.x resta aperta permanentemente - non esiste patch ufficiale
• Le librerie Composer moderne richiedono PHP 8.1+ come versione minima, isolando l'applicativo dall'ecosistema
• I framework Laravel (dalla versione 11) e Symfony (dalla versione 7) richiedono PHP 8.2+
• Il mancato aggiornamento del software che tratta dati personali può configurare una violazione del principio di sicurezza del GDPR (articolo 32) e dei requisiti NIS2

Le differenze tecniche tra PHP 5 e PHP 8

La distanza tra PHP 5.6 e PHP 8.x non è un semplice aggiornamento incrementale - è un cambio generazionale del linguaggio. I breaking change principali attraversano tre major version.

Da PHP 5.6 a 7.0, le modifiche più impattanti sono state la rimozione completa delle funzioni mysql_* (sostituite da PDO e MySQLi), la rimozione dei tag ASP (<%), la nuova gestione delle variabili uniformi, e la promozione di molti errori fatali a eccezioni catchable. Un applicativo che usa mysql_connect() e mysql_query() richiede una riscrittura completa del layer di accesso al database.

Da PHP 7.x a 8.0, i cambiamenti principali sono la promozione di warning a TypeError e ValueError (il codice che "funzionava con warning" ora genera eccezioni), l'introduzione di union types, named arguments, match expression, e la rimozione di funzioni legacy come each() e create_function().

PHP 8.1-8.5 aggiungono funzionalità che modernizzano radicalmente il linguaggio: enum, readonly properties e classi, fibre per la programmazione asincrona, e il JIT compiler che migliora significativamente le performance su workload computazionali. Ecco un confronto concreto dello stesso codice in PHP 5.6 e PHP 8.4:

<?php
declare(strict_types=1);

enum OrderStatus: string              /* enum (PHP 8.1+) */
{
    case Pending = 'pending';
    case Confirmed = 'confirmed';
    case Shipped = 'shipped';
    case Cancelled = 'cancelled';
}

readonly class OrderSummary            /* readonly class (PHP 8.2+) */
{
    public function __construct(
        public int $id,
        public OrderStatus $status,
        public float $total,
        public \DateTimeImmutable $createdAt,
    ) {}
}

function getOrderSummary(
    \PDO $db,
    int $orderId,
): ?OrderSummary {                     /* nullable return type */
    $stmt = $db->prepare(
        'SELECT id, status, total, created_at FROM orders WHERE id = :id'
    );
    $stmt->execute(['id' => $orderId]);
    $row = $stmt->fetch(\PDO::FETCH_ASSOC);

    return match (true) {              /* match expression (PHP 8.0+) */
        $row === false => null,
        default => new OrderSummary(
            id: $row['id'],            /* named arguments (PHP 8.0+) */
            status: OrderStatus::from($row['status']),
            total: (float) $row['total'],
            createdAt: new \DateTimeImmutable($row['created_at']),
        ),
    };
}

In PHP 5.6, lo stesso codice richiederebbe classi con getter e setter manuali, nessun type hint sui parametri scalari, nessuna dichiarazione di tipo di ritorno, mysql_query() senza prepared statement, e switch/case al posto di match. Il codice PHP 8 è più sicuro (type safety), più leggibile (meno boilerplate), e più performante (ottimizzazioni del runtime).

Il percorso di migrazione: strumenti e strategia

Una migrazione da PHP 5.6 a PHP 8.x non si fa in un giorno, ma con gli strumenti giusti il processo è sistematico e gestibile.

Il primo passo è l'analisi di compatibilità. PHPCompatibility, un ruleset per PHP_CodeSniffer, scansiona il codice sorgente e identifica ogni incompatibilità con la versione target: funzioni rimosse, parametri cambiati, sintassi non più supportata. Il report risultante è la mappa precisa del lavoro necessario.

Il secondo passo è la correzione automatizzata. Rector analizza il codice e applica trasformazioni automatiche: converte mysql_* in PDO, aggiunge type hint, modernizza la sintassi. Con il set LevelSetList::UP_TO_PHP_84, Rector gestisce automaticamente la maggior parte delle trasformazioni meccaniche, lasciando il lavoro manuale concentrato sulla logica di business e sulle scelte architetturali.

Il terzo passo è la validazione con analisi statica. PHPStan al livello massimo verifica la correttezza dei tipi, identifica codice morto e segnala potenziali errori runtime - una rete di sicurezza che intercetta i problemi introdotti dalla migrazione prima che raggiungano la produzione.

Il workflow consigliato: PHPCompatibility scan → PHPStan al livello corrente → Rector --dry-run → revisione del diff → applicazione → PHPStan al livello target → test suite. Ho descritto strategie complementari per il refactoring del codice PHP legacy e per l'aggiornamento dei framework Symfony e Laravel.

Performance: i numeri della migrazione

Le migliorie di performance non sono un argomento di marketing - sono misurabili. I benchmark di Kinsta su workload reali (WordPress, Laravel, Symfony) mostrano che il passaggio da PHP 7.4 a 8.x produce circa il 5% di incremento nel throughput con una riduzione del 27% nell'uso di memoria per worker. Su workload computazionali intensivi, il JIT compiler di PHP 8.x produce miglioramenti fino all'82% su Laravel e al 95% su Symfony.

Per un applicativo che serve centinaia di richieste al minuto, la riduzione del 27% di memoria per worker significa poter servire più richieste concorrenti con lo stesso hardware - o ridurre le risorse server mantenendo le stesse performance. Combinato con il refactoring delle query database e l'ottimizzazione dell'infrastruttura, la migrazione a PHP 8 può trasformare radicalmente il profilo di costo e performance di un applicativo legacy.

Ogni mese in cui un applicativo resta su PHP 5 o PHP 7 è un mese in cui accumula debito tecnico, rischio di sicurezza e distanza dall'ecosistema moderno. Gli strumenti per la migrazione esistono, sono maturi e automatizzano la parte meccanica del lavoro. Per conoscere il mio approccio alla modernizzazione di applicativi PHP, visita la mia pagina professionale. Se il tuo applicativo critico gira su una versione PHP fuori supporto e vuoi pianificare una migrazione sicura, contattami per una consulenza dedicata - partiamo dall'analisi di compatibilità del tuo codebase.