Codice custom su PHP 8.
Senza riscrivere l’applicazione.
Portiamo su PHP 8 gestionali e portali scritti senza framework, sostituendo mysql_* con PDO e introducendo Composer, autoload e test prima di toccare la logica.
Per applicazioni nate quindici o vent’anni fa, cresciute per aggiunte con catene di include, funzioni globali e librerie copiate a mano, ferme su PHP 5 o 7 perché ogni modifica fa paura.
Dal ramo che hai.
Al ramo supportato.
Nel codice custom il percorso segue i rami di PHP. Le due tappe che rompono più codice sono PHP 7.0 e PHP 8.0, quindi prima mettiamo ordine e creiamo i test, poi attraversiamo i rami uno alla volta.
- 01Codice su PHP 5.xPHP 5.6
Funzioni mysql_*, ereg e include a catena, nessun test
- 02Composer e testPHP in uso
Autoload e test di caratterizzazione, senza cambiare il comportamento
- 03PDO e PHP 7.4PHP 7.4
Uno strato di accesso unico al database e le deprecazioni della serie 7 corrette
- 04PHP 8 supportatoPHP 8.3 – 8.5
Rimozioni di PHP 8.0 e cambi di comportamento verificati con i test
Cosa si rompe.
Ramo per ramo.
Le rimozioni e i cambiamenti che incontriamo più spesso nel codice legacy, secondo le guide di migrazione del manuale di PHP.
Fonti: Migrazione a PHP 7.0 · Migrazione a PHP 8.0 · Rami di PHP non più supportati. La matrice dei rami di PHP con le distribuzioni Linux è nella pagina Versioni PHP.
Cosa blocca l’upgrade.
E come lo sblocchiamo.
Senza un framework ogni progetto ha una struttura propria. I blocchi però si ripetono quasi sempre negli stessi punti.
Accesso al database con mysql_*
Le funzioni mysql_* non esistono più da PHP 7.0 e sono sparse in centinaia di file. Le concentriamo in uno strato di accesso unico basato su PDO, poi parametrizziamo le query a partire da quelle che ricevono dati dall’esterno.
Include a catena
L’ordine delle inclusioni è fragile e la stessa classe arriva da percorsi diversi. Con Composer usiamo classmap per il codice esistente, psr-4 per quello nuovo e files per le funzioni globali.
Nessun test
Senza test l’unico modo di scoprire una regressione è la segnalazione di un utente. Scriviamo test di caratterizzazione che fissano il comportamento attuale dei flussi critici, come login, ordini e fatturazione.
Librerie copiate a mano
Generatori di PDF, client SOAP e classi per l’email sono spesso versioni vecchie, a volte modificate. Le confrontiamo con l’originale e le sostituiamo con i pacchetti mantenuti, aggiornandole per gradi.
Errori che non si vedono
Confronti tra numeri e stringhe, avvisi promossi a eccezioni e costruttori in stile PHP 4 non danno errori di sintassi. Li cerchiamo con PHPCompatibility, PHPStan ed esecuzione con error_reporting = E_ALL.
Dati cifrati e charset
Con mcrypt serve sapere algoritmo, modalità e padding prima di cambiare libreria. Con il passaggio a PDO verifichiamo anche il charset della connessione, per non rovinare i caratteri accentati salvati negli anni.
Il nostro intervento.
Passo dopo passo.
Se la migrazione richiede tempo, nel frattempo teniamo protetto il PHP in uso con il backport delle patch di sicurezza.
- 01INVENTARIO
Inventario e matrice
Rileviamo versione di PHP ed estensioni in produzione, librerie incluse e flussi critici. Con ricerca testuale e analisi statica misuriamo la distanza da PHP 8, file per file.
- 02STAGING
Ordine prima delle modifiche
Introduciamo Composer, l’autoload e i test di caratterizzazione senza cambiare il comportamento, così possono andare in produzione presto. Sulle versioni vecchie di PHP usiamo Composer 2.2 LTS.
- 03UPGRADE
Correzioni per gradi
Sostituiamo
mysql_*con PDO e correggiamo le incompatibilità ramo per ramo, in un ambiente di prova con l’applicazione reale. Le modifiche compatibili con entrambe le versioni escono subito. - 04RILASCIO
Rilascio e ponte
Il rilascio sul nuovo PHP avviene con Ansible e un piano di rollback. Fino ad allora il backport delle patch di sicurezza tiene protetto il PHP fuori supporto in uso.
Per approfondire.
Codice PHP “vanilla” senza framework: come introdurre Composer, autoload e test
Come portare Composer, l’autoload con classmap, PSR-4 e files e i primi test di caratterizzazione con PHPUnit in un’applicazione PHP senza framework, senza riscriverla e senza cambiarne il comportamento, come base per la migrazione a PHP 8.
Leggi l’approfondimentoDa mysql_* a PDO: riscrivere l’accesso al database senza riscrivere l’applicazione
Come sostituire le funzioni mysql_*, rimosse in PHP 7.0, con PDO in modo graduale: uno strato di accesso unico, la connessione configurata bene, le corrispondenze tra funzioni, le query parametrizzate e le differenze da verificare prima del rilascio.
Leggi l’approfondimentoGestionali custom su PHP vecchio: stimare tempi e costi della migrazione
Quali fattori determinano tempi e costi della migrazione di un gestionale custom su PHP fuori supporto, come misurarli sul codice, come usare la stima a tre punti per esprimere l’incertezza e cosa deve contenere un preventivo serio.
Leggi l’approfondimentoPrima di iniziare.
Le domande che ci fanno più spesso su PHP Vanilla e PHP.
Bisogna adottare un framework per migrare?
No. Composer e PHPUnit si aggiungono accanto al codice esistente e non richiedono di riorganizzare il progetto. La parte nuova cresce con namespace e psr-4, mentre quella storica si riduce una classe alla volta.
Meglio PDO o mysqli?
Entrambe sono mantenute e adatte alla produzione. Preferiamo PDO per i segnaposto con nome, gli errori gestiti con eccezioni e l’interfaccia unica per database diversi. Il metodo dello strato di accesso unico è lo stesso con tutte e due.
Posso usare Composer su PHP 5.6?
Sì. Le versioni correnti di Composer richiedono PHP 7.2.5 o superiore, mentre il ramo di supporto a lungo termine 2.2 funziona da PHP 5.3.2. Anche PHPUnit va scelto in base al PHP in uso, per esempio PHPUnit 5 su PHP 5.6.
Come si stima il lavoro?
Con un inventario fatto prima di aprire il primo file. Una ricerca delle funzioni rimosse dà l’ordine di grandezza in pochi minuti, l’analisi statica e l’esecuzione con tutti gli avvisi attivi completano il quadro. Da lì si capisce se il problema riguarda dieci file o trecento.
Aggiorniamo
il tuo codice.
Indicaci versione della piattaforma, versione di PHP e sistema operativo. Ti risponderemo con una prima valutazione del percorso di upgrade e di cosa serve per arrivarci.
Richiedi una valutazioneLunedì – venerdì · 09:30 – 19:30
+39 340 985 4556 ↗