Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso
Le scadenze EOL di PHP non sono un dettaglio da sysadmin: sono una leva di rischio per chi resta indietro. Lo stato reale nel 2026, con le date dal dossier: 8.3 già in security-only, 8.4 in supporto attivo fino a fine anno, 8.2 fuori dalla sicurezza a fine 2026. Il piano di migrazione da avviare adesso per chi è su 8.2 o 8.3: checklist, deprecazioni da gestire, test, e perché aspettare l'ultimo trimestre è la scelta più costosa. Continua a leggere
Ultima modifica:
PHP 8.5 introduce il pipe operator, e la domanda onesta è se migliori davvero la leggibilità o sia solo zucchero sintattico. Analisi pratica: cosa risolve davvero, ovvero le chain leggibili da sinistra a destra; i limiti reali con i callable a più parametri e i built-in da wrappare; e gli esempi da codice gestionale dove il pipe rende il flusso chiaro contro quelli dove aggiunge solo una sintassi nuova. Onesto sui tradeoff, non entusiasta per default. 
Migrare un'applicazione legacy da PHP 7.4 a 8.3 è un progetto di rischio gestito, non un aggiornamento al volo. Checklist concreta: i breaking changes che mordono davvero, le deprecazioni da intercettare prima del deploy, la strategia incrementale per non fermare la produzione e la suite di test che fa da rete. Con le date EOL aggiornate, perché restare su 7.4 nel 2026 non è più un'opzione di sicurezza. 
"Laravel è la scelta migliore" è il tipo di affermazione di cui diffido, perché nessuno strumento è il migliore per tutto. Eppure, quando un cliente mi chiede su cosa costruire una nuova applicazione web aziendale, nella maggioranza dei casi la mia risposta è Laravel, e non per moda: è una scelta di ingegneria, fondata su velocità di sviluppo, manutenibilità ed ecosistema. Vediamo perché lo scelgo, cosa lo distingue nel 2026, e quando invece consiglio altro. 
OPcache è la singola ottimizzazione PHP con il maggiore impatto sulle prestazioni: su una applicazione Laravel media, la configurazione corretta riduce il tempo di risposta del 40-60%. Ma la configurazione di default non è ottimale per la produzione. Vi mostro i parametri che cambio sempre e perché. 
Un e-commerce B2B con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
I worker Laravel Horizon di un cliente consumavano 500MB di RAM dopo 6 ore di esecuzione e venivano killati automaticamente. Il memory leak non era ovvio: un event listener registrato globalmente teneva riferimenti a ogni job processato. Vi mostro il processo di diagnosi con Blackfire e le strategie di correzione. 
La sessione PHP è uno dei vettori di attacco più sottovalutati. In un assessment su un portale bancario PHP, ho dimostrato session fixation in meno di 10 minuti sfruttando un PHPSESSID passato in query string. Vi mostro la configurazione php.ini che elimina la classe di vulnerabilità e i pattern di sessione sicura per Laravel. 
PHP 8.4 introduce lazy objects nativi che permettono di ritardare l'inizializzazione di servizi pesanti fino al primo utilizzo, senza proxy manuali. Ho testato l'impatto su un'applicazione Symfony con 80 servizi registrati nel container: il tempo di bootstrap dell'applicazione è sceso del 35% con 8 righe di configurazione. 
Ogni codebase PHP legacy che eredo ha la stessa peste: costanti integer o stringhe magiche per rappresentare stati di business. ORDINE_STATO_1, ORDINE_STATO_2. Con PHP 8 Enums, ho modernizzato un sistema ordini trasformando 40 costanti sparse in enum tipizzati con metodi di dominio. Il codice è diventato leggibile.