App Upgrading.
La tua app su PHP 8.x.
Portiamo CMS, e-commerce, framework e codice custom da PHP 5 e 7 a un ramo di PHP 8 supportato, aggiornando insieme codice, temi, plugin, moduli e librerie.
Senza riscrivere l’applicazione e senza fermarla: lavoriamo su una copia di prova, una versione alla volta, e passiamo in produzione con un piano di rollback.
Aggiornare PHP
vuol dire aggiornare il codice.
Ogni ramo di PHP rimuove qualcosa che il precedente aveva deprecato. Un’applicazione scritta per PHP 5 o 7 non si ferma per un solo motivo: per questo lavoriamo sull’applicazione intera, non sul solo interprete.
- PHP 7.0
Le prime funzioni sparite.
Vengono rimosse l’estensione
mysqlcon tutte le funzionimysql_*,mssqle le funzioniereg. Molti errori fatali diventano eccezioniError, che un vecchio gestore non intercetta. - PHP 7.1 – 7.4
Le deprecazioni si accumulano.
In PHP 7.2
mcryptesce dalla distribuzione standard e diventano deprecatieach()ecreate_function(). PHP 7.4 aggiunge avvisi permoney_format()eget_magic_quotes_gpc(). - PHP 8.0
La seconda grande pulizia.
Le funzioni deprecate nella serie 7 vengono rimosse. Il codice che passava con un avviso ora si ferma con un errore fatale, spesso su una pagina che nessuno apre da anni.
- PHP 8.1 – 8.4
Le abitudini da cambiare.
Diventano deprecati
nullpassato alle funzioni interne, comestrlen(null),strftime(), le proprietà dinamiche delle classi eutf8_encode(). Oggi sono avvisi, nelle prossime versioni saranno errori.
Fonte: guide di migrazione di php.net. L’elenco completo è nell’articolo Funzioni rimosse in PHP 8.
Quattordici piattaforme.
Un percorso per ciascuna.
Ogni piattaforma ha le sue tappe obbligate, i suoi requisiti di PHP e i suoi punti deboli. Scegli la tua per vedere il percorso di upgrade, la tabella delle versioni e cosa troviamo di solito.
CMS
E-COMMERCE
WooCommerce
Pagamenti e ordini al sicuro.
Negozio legacy → HPOS attivoAggiornamento WooCommerce
PrestaShop
Clienti e ordini al loro posto.
PrestaShop 1.6.1 → PrestaShop 9.1Aggiornamento PrestaShop
Magento
Da Magento 1 a 2 o a OpenMage.
Magento 1.9 o 1.14 → Magento 2.4.9Aggiornamento Magento
OpenCart
Negozio, tema ed estensioni.
OpenCart 1.5.6.4 → OpenCart 4.1.0.4Aggiornamento OpenCartFRAMEWORK
Laravel
Una major alla volta.
Laravel 6 → Laravel 13Aggiornamento Laravel
Symfony
Da una LTS all’altra.
Symfony 2.8 o 3.4 LTS → Symfony 7.4 LTSAggiornamento Symfony
Yii
Yii 1.1, Yii 2 e il passo dopo.
Yii 1.1 prima della 1.1.23 → Yii3Aggiornamento Yii
Zend Framework
ZF1, Laminas e Mezzio.
Zend Framework 1.12 → Mezzio 3Aggiornamento Zend Framework
CodeIgniter
Da CodeIgniter 3 al 4.
CodeIgniter 2.x → CodeIgniter 4.7Aggiornamento CodeIgniter
CakePHP
Dal ramo 2.x al 5.x.
CakePHP 1.3 → CakePHP 5.4Aggiornamento CakePHP
Una tappa alla volta.
Sempre con il rollback.
Lo stesso metodo per un sito WordPress e per un gestionale scritto a mano: analisi, prova, aggiornamento per gradi e rilascio controllato.
- 01INVENTARIO
Analisi e matrice
Versioni di PHP, CMS, temi, plugin, moduli e librerie, con l’analisi statica del codice e una matrice di compatibilità verso il ramo di arrivo.
- 02STAGING
Ambiente di prova
Una copia dell’applicazione reale, con i suoi dati, su cui lavorare senza toccare la produzione.
- 03UPGRADE
Una versione alla volta
Rami intermedi quando servono, correzioni del codice, sostituzione dei componenti abbandonati e test dei percorsi critici a ogni passaggio.
- 04RILASCIO
In produzione con il rollback
Rilascio pianificato, verifiche dopo il passaggio e ritorno indietro già pronto se qualcosa non va.
Un progetto chiaro.
Dall’analisi al rilascio.
Prima di toccare il codice sai cosa va fatto, in che ordine e con quale sforzo. Alla fine hai un’applicazione su PHP supportato e la documentazione per i prossimi aggiornamenti.
- 01
Report di compatibilità
Cosa funziona già, cosa va corretto, cosa va sostituito, con priorità e stime.
- 02
Piano per tappe
L’ordine degli aggiornamenti di PHP, piattaforma e componenti, con i rami intermedi.
- 03
Codice aggiornato
Le modifiche nel tuo repository, leggibili e documentate, senza dipendenze nascoste.
- 04
Test e verifiche
I controlli eseguiti sui percorsi critici, ripetibili ai prossimi aggiornamenti.
Protetto oggi.
Aggiornato domani.
Un upgrade fatto bene richiede tempo. Nel frattempo il PHP in uso resta esposto alle vulnerabilità pubblicate dopo l’End of Life: con il Patching chiudiamo le CVE sul ramo installato, così l’upgrade procede senza fretta.
Per approfondire.
Migrare un CMS a PHP 8: perché si aggiorna sempre tutto lo stack
Perché portare un CMS su PHP 8 significa aggiornare core, estensioni, tema e codice su misura, quali sono i requisiti di WordPress, WooCommerce, PrestaShop, Joomla e Drupal, in che ordine procedere e come proteggere la produzione durante il lavoro.
Leggi l’approfondimentoDa PHP 5 a PHP 8: le funzioni rimosse che bloccano il tuo codice
Quali funzioni sono sparite in PHP 7.0 e in PHP 8.0, con cosa si sostituiscono, quali cambiamenti di comportamento rompono il codice senza errori evidenti e come fare l’inventario completo prima di iniziare la migrazione.
Leggi l’approfondimentoAnalisi statica per la migrazione: PHPCompatibility, PHPStan e Rector in pratica
Come trovare i problemi di una migrazione a PHP 8 prima di cambiare versione: cosa fanno PHPCompatibility, Rector e PHPStan, come configurarli su un progetto legacy, in quale ordine usarli e cosa resta da verificare con i test.
Leggi l’approfondimentoPrima di iniziare.
Le domande che ci fanno più spesso su tempi, rischi e costi di un upgrade.
Serve riscrivere l’applicazione?
Quasi mai. Nella maggior parte dei casi il codice si aggiorna per parti: si sostituiscono le funzioni rimosse, si aggiornano le librerie e la piattaforma, si correggono i punti che le nuove versioni segnalano. La riscrittura ha senso solo quando il framework non ha più un percorso di aggiornamento, e lo diciamo nel report iniziale.
Il sito resta online durante l’upgrade?
Sì. Lavoriamo su un ambiente di prova con una copia dell’applicazione e dei dati, e passiamo in produzione solo dopo i test, in un momento concordato e con il ritorno indietro pronto.
Nel frattempo il PHP vecchio resta esposto?
Se l’upgrade richiede settimane o mesi, il PHP in uso resta protetto con il nostro Patching: il backport delle patch di sicurezza sul ramo installato, fino al passaggio a PHP 8.x.
Come si stimano tempi e costi?
Dall’analisi iniziale: versioni, quantità di codice personalizzato, componenti da sostituire e copertura dei test. Il report indica le tappe e lo sforzo di ciascuna, così puoi decidere con i numeri del tuo progetto.
Aggiorniamo
la tua app.
Indicaci 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 ↗