CodeIgniter su PHP 8.
Da CodeIgniter 3 al 4.
Portiamo le applicazioni CodeIgniter 2 e 3 su un PHP supportato e le convertiamo a CodeIgniter 4, che è una riscrittura del framework, conservando logica di business e database.
Per chi ha un gestionale o un sito su CodeIgniter fermo su PHP 5 o 7 e non sa se aggiornare il ramo 3 o passare al 4. Stimiamo il lavoro, proteggiamo la produzione e migriamo per parti.
Dal ramo che hai.
Al ramo supportato.
CodeIgniter 2 si porta prima sull’ultima versione del ramo 3, che è stata adattata a PHP 8.0 e 8.1. Il passaggio a CodeIgniter 4 è una conversione dell’applicazione, perché il framework è stato riscritto e non è retrocompatibile.
- 01CodeIgniter 2.xPHP 5.x
Ramo storico, da allineare prima al 3.1 per cartelle, sessioni e librerie.
- 02CodeIgniter 3.1.13da PHP 5.3.7, adattato a 8.1
Ultimo rilascio del ramo 3, di marzo 2022, senza data di fine annunciata.
- 03CodeIgniter 4.0 – 4.4da PHP 7.2, poi 7.4
Riscrittura con namespace, cartella public e PSR-4. Tappa utile per chi resta su PHP 7.
- 04CodeIgniter 4.7PHP 8.2 o superiore
Ramo corrente, con aggiornamenti minori documentati versione per versione.
Versioni e PHP.
Ramo per ramo.
Il requisito minimo di PHP di CodeIgniter 4 è cresciuto con le versioni minori. Lo stato è quello di novembre 2026.
Fonti: Requisiti di CodeIgniter 4 · Requisiti di CodeIgniter 3 · Da CodeIgniter 3 a CodeIgniter 4. La matrice dei rami di PHP con le distribuzioni Linux è nella pagina Versioni PHP.
Cosa blocca l’upgrade.
E come lo sblocchiamo.
La guida ufficiale invita a pensare il passaggio a CodeIgniter 4 come una conversione dell’applicazione. Questi sono i punti che richiedono più lavoro.
Il 4 non è retrocompatibile
CodeIgniter 4 è una riscrittura e non esiste uno strumento ufficiale di conversione automatica. Partiamo da un’installazione pulita e portiamo controller, modelli e viste un gruppo alla volta.
Superoggetto e caricamento
Nel ramo 3 tutto passa da $this->load e dal superoggetto del controller. Nel 4 si usano namespace, autoload PSR-4, Services e Factories, quindi rivediamo ogni punto in cui l’applicazione carica librerie e modelli.
Librerie e helper rimossi
Nel 4 mancano librerie come Calendaring, FTP, Shopping Cart, XML-RPC e Zip, e alcuni helper sono stati rimossi o accorpati. Per ognuno scegliamo un pacchetto Composer mantenuto o una sostituzione nel codice.
Hook, MY_ e core estesi
Gli hook diventano Events e filtri dei controller, e spariscono il prefisso MY_ e la cartella core. Le personalizzazioni del framework vanno riscritte come servizi registrati in app/Config/Services.php.
Ramo 3 sui PHP più recenti
La 3.1.12 ha adattato il framework a PHP 8.0 e 8.1, ma il codice applicativo spesso non segue. Sulle versioni successive di PHP emergono deprecazioni come quelle sulle proprietà dinamiche, che correggiamo prima del cambio.
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
Censiamo controller, modelli, librerie, helper e personalizzazioni del core. Ne ricaviamo una matrice di compatibilità e la scelta tra aggiornare il ramo 3 o convertire al 4.
- 02STAGING
Ambiente di prova reale
Prepariamo un ambiente di prova con l’applicazione reale e una copia dei dati. Lì correggiamo il codice per PHP 8 con PHPCompatibility, PHPStan e Rector prima di toccare il framework.
- 03UPGRADE
Conversione per parti
Convertiamo una sezione alla volta, coprendo con test i percorsi critici. Quando serve facciamo convivere il ramo 3 e il 4 sullo stesso dominio e sullo stesso database.
- 04RILASCIO
Rilascio e ponte di sicurezza
Rilasciamo con Ansible e un piano di rollback provato. Se la conversione richiede tempo, il backport delle patch di sicurezza protegge il PHP in uso nel frattempo.
Per approfondire.
Gestionali 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’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 CodeIgniter e PHP.
CodeIgniter 3 è ancora supportato?
Il progetto non ha annunciato una data di fine ufficiale per il ramo 3. L’ultimo rilascio è la 3.1.13 di marzo 2022. Tutto lo sviluppo attivo è su CodeIgniter 4. Lo consideriamo un ramo da cui pianificare l’uscita.
Basta aggiornare CodeIgniter 3 per arrivare a PHP 8?
La 3.1.12 ha adattato il framework a PHP 8.0 e 8.1, quindi per un primo passo può bastare. Il codice applicativo va comunque corretto per le funzioni rimosse e le deprecazioni. Per arrivare ai PHP più recenti con un framework mantenuto serve CodeIgniter 4.
Quanto costa passare da CodeIgniter 3 a CodeIgniter 4?
Dipende da quanto l’applicazione usa librerie, helper e personalizzazioni del core. Lo stimiamo dopo l’inventario, sezione per sezione. Logica di business e schema del database di solito si conservano.
Aggiorniamo
il tuo progetto.
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 ↗