Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026
Le funzioni mysql_ di PHP sono deprecate dalla 5.5 e rimosse dalla 7.0. Un'applicazione che le contiene ancora gira per forza su una versione di PHP fuori supporto da circa dieci anni: non un problema di stile, ma una falla di sicurezza che cammina. Questo articolo rifà la guida al porting con l'occhio del 2026: cosa fa un convertitore automatico e dove ti lascia scoperto, mysqli o PDO, e perché la posta in gioco non è la deprecazione ma l'SQL injection che il vecchio codice si porta dietro. Continua a leggere
Ultima modifica:
La prima settimana su un progetto legacy è sempre disorientante. Ho sviluppato un processo sistematico di audit tecnico in 5 fasi: analisi statica con PHPStan, complessità ciclomatica con PHP Metrics, mappa delle dipendenze esterne, test di copertura esistente e interviste al team. Output: un report con priorità chiare. 
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. 
Ho migrato tre applicazioni da Symfony 5 a Symfony 7 in produzione. Il percorso non è una singola migrazione: si passa per Symfony 6 gestendo ogni set di deprecation progressivamente. Vi racconto i breaking change che mi hanno sorpreso di più, le scorciatoie che non funzionano e il processo sistematico che uso. 
Migrare 200.000 righe di PHP da 7.4 a 8.3 manualmente è un progetto da 2-3 mesi. Con un workflow LLM-assisted scende a 2-3 settimane senza sacrificare qualità. Nella mia pipeline combino Rector per le trasformazioni meccaniche, Claude per i breaking change complessi, test caratterizzanti generati dal LLM, regression testing incrementale. Ti mostro il workflow reale con tempi giornalieri e le trappole tipiche. 
Un CTO mi ha chiesto di convincere il suo CEO a investire in refactoring. Ho costruito un modello di costo basato su dati reali: tempo medio per aggiungere una feature, numero di bug per rilascio, costo orario del team. Il debito tecnico costava all'azienda 180.000€/anno in produttività persa. Il CEO ha approvato. 
La 'riscrittura totale' è quasi sempre un errore. Con il pattern Strangler Fig ho aiutato una società logistica a estrarre gradualmente funzionalità dal loro monolite Laravel: prima il modulo di tracking, poi la fatturazione. Due anni dopo, tre microservizi autonomi e il monolite ridotto del 40%, sempre in produzione. 
Modernizzare un'applicazione PHP 7.4 a PHP 8.3 non significa riscrivere tutto - significa sfruttare le nuove feature dove migliorano la leggibilità e la sicurezza. Vi mostro il processo che uso: identificare i candidati giusti per match expression e named arguments, refactoring sicuro con test a tappeto. 
Ho ereditato un'API Laravel usata da 40 integratori terzi senza versioning. Aggiungere un campo obbligatorio era un problema diplomatico prima che tecnico. Vi mostro le strategie di versioning che ho adottato, come ho introdotto il versioning retroattivamente e il contratto di deprecation che uso con i clienti API. 
Un gestionale PHP legacy con zero test e 3 regressioni al mese: ogni fix rompeva qualcosa. In 5 giorni ho introdotto 28 smoke test HTTP e 12 snapshot test sulle funzioni di calcolo - senza toccare il codice applicativo. Regressioni in produzione scese da 3/mese a zero nel primo trimestre.