Yii 1.1 è stato uno dei framework PHP più usati tra il 2010 e il 2015, e molte applicazioni costruite allora sono ancora in produzione: gestionali, portali per i clienti, pannelli di amministrazione. Spesso girano su PHP 5.x, perché chi le ha scritte dava per scontato che il framework non funzionasse sulle versioni nuove. In realtà negli ultimi anni il ramo 1.1 ha ricevuto aggiornamenti proprio per restare compatibile con PHP 8.
C’è però una scadenza vicina. Secondo il calendario del progetto, Yii 1.1 arriva a fine vita il 31 dicembre 2026. In questo articolo vediamo cosa si può fare oggi con un’applicazione Yii 1.1: aggiornare il ramo per portarla su un PHP supportato, cosa succede dopo la fine del supporto, e quando conviene invece migrare a Yii 2 o a Yii3.
Dove si trova Yii 1.1 oggi
La pagina del ciclo di rilascio di Yii riassume la storia del ramo: rilasciato a gennaio 2010, in congelamento delle funzionalità da novembre 2015, solo correzioni di sicurezza dal 1° gennaio 2017, fine vita il 31 dicembre 2026. In questa fase di manutenzione il progetto ha pubblicato correzioni di sicurezza e, soprattutto, adattamenti alle nuove versioni di PHP, senza modifiche che rompano la compatibilità.
Il risultato è che un’applicazione Yii 1.1 può girare su un PHP moderno, a condizione di usare una versione recente del framework. Il registro delle modifiche indica in quale versione è arrivato il supporto per ciascun ramo di PHP:
| Versione di Yii | Data | Novità per la compatibilità |
|---|---|---|
| 1.1.23 | dicembre 2020 | supporto per PHP 8 |
| 1.1.26 | settembre 2022 | supporto per PHP 8.1 |
| 1.1.28 | febbraio 2023 | supporto per PHP 8.2 |
| 1.1.30 | ottobre 2024 | supporto per PHP 8.3 |
| 1.1.31 | aprile 2025 | correzione della vulnerabilità CVE-2025-32027 |
| 1.1.32 | dicembre 2025 | supporto per PHP 8.4 |
| 1.1.33 | in sviluppo | supporto per PHP 8.5 |
Aggiornare il ramo 1.1
Passare da una versione vecchia di Yii 1.1, per esempio la 1.1.14 o la 1.1.16, all’ultima disponibile è di solito il lavoro più conveniente che si possa fare su queste applicazioni. Le istruzioni di aggiornamento ufficiali sono cumulative: bisogna leggere quelle di ogni versione intermedia, ma per le versioni più recenti riportano quasi sempre l’assenza di modifiche significative. Il procedimento di base è questo:
# 1. Quale versione di Yii usa l’applicazione
grep -A 3 "function getVersion" framework/YiiBase.php
# 2. Sostituire il framework: con l’archivio scaricato da yiiframework.com,
# oppure con Composer (in index.php il percorso diventa
# vendor/yiisoft/yii/framework/yii.php)
composer require yiisoft/yii:1.1.32
# 3. Svuotare la cartella degli asset pubblicati nella cartella web:
# Yii li rigenera alla prima richiesta
rm -rf web/assets/*
Prima del rilascio conviene aprire il controllo dei requisiti incluso nella distribuzione, requirements/index.php, sul server di destinazione, e poi provare l’applicazione su un ambiente di prova con la nuova versione di PHP e tutti gli avvisi attivi. Aggiornare il framework, infatti, risolve solo una parte del problema.
Tra le istruzioni da leggere con attenzione c’è quella per chi parte dalla 1.1.23 o da una versione precedente: nel rilascio successivo jQuery UI è stato aggiornato alla 1.12, con possibili differenze nell’aspetto e nel comportamento dei widget che lo usano, come i selettori di date e le finestre di dialogo. Il vecchio tema grafico resta incluso e configurato come predefinito, ma le pagine con widget JavaScript vanno provate anche nel browser, oltre che lato server. Lo stesso vale per le estensioni che includono proprie copie di jQuery o di altre librerie JavaScript, che possono entrare in conflitto con quelle aggiornate dal framework.
Il codice dell’applicazione e le estensioni
Il framework aggiornato funziona su PHP 8. Il codice scritto sopra il framework va reso compatibile a parte, e nelle applicazioni Yii 1.1 i problemi si concentrano in tre punti:
- il codice applicativo: controller, modelli e viste scritti per PHP 5 contengono le stesse incompatibilità di qualunque altro progetto dell’epoca, dalle funzioni rimosse in PHP 8 ai nuovi confronti tra numeri e stringhe;
- le estensioni di terze parti: widget, generatori di PDF, client di servizi esterni scaricati anni fa dal catalogo delle estensioni. Molte non sono più mantenute e vanno corrette a mano o sostituite;
- le librerie copiate in
protected/vendoro inprotected/extensions, spesso versioni molto vecchie di pacchetti che oggi si installano con Composer.
Un caso specifico riguarda le proprietà dinamiche, deprecate da PHP 8.2. Le classi che estendono i componenti di Yii, come CModel e CActiveRecord, gestiscono le proprietà con i propri metodi magici e non sono toccate dall’avviso; lo sono invece le classi scritte senza estendere il framework, come helper e servizi, quando ricevono proprietà non dichiarate. Per trovare tutto in anticipo usiamo gli strumenti descritti nell’articolo sull’analisi statica per la migrazione, escludendo la cartella del framework dall’analisi.
Cosa succede dopo il 31 dicembre 2026
Dopo la fine vita il progetto non pubblicherà più correzioni per il ramo 1.1, né di sicurezza né di compatibilità. Un’applicazione aggiornata a Yii 1.1.32 su PHP 8.4 resta comunque in una posizione molto migliore di una ferma su PHP 5.6: PHP 8.4 riceve correzioni di sicurezza fino al 31 dicembre 2028, e il framework ha già incorporato le correzioni note fino alla fine del supporto.
Restano due rischi da gestire. Il primo è una nuova vulnerabilità nel codice di Yii 1.1, che a quel punto andrà corretta in proprio, nel repository dell’applicazione. Il secondo è il tempo: PHP 8.4 a sua volta uscirà dal supporto, e senza nuovi rilasci del framework il passaggio alle versioni successive di PHP richiederà di adattare da sé il codice di Yii. Per questo l’aggiornamento del ramo va visto come un modo per guadagnare due o tre anni di tempo, da usare per pianificare la migrazione.
Migrare a Yii 2
Come spiega la guida ufficiale, Yii 2.0 è stato riscritto da zero, e passare dalla 1.1 non è banale come un aggiornamento tra versioni minori. Cambiano gli spazi dei nomi, l’installazione con Composer, la configurazione degli oggetti, gli eventi, i form, i widget, il query builder e Active Record. In pratica si riscrivono controller, viste e buona parte dei modelli, conservando lo schema del database e la logica di business.
La stessa guida dedica una sezione all’uso di Yii 1.1 e Yii 2 nella stessa applicazione, che permette una migrazione per sezioni invece di un rilascio unico. Va però considerato lo stato del ramo 2.0: secondo la pagina del ciclo di rilascio, le versioni dalla 2.0.50 richiedono PHP 7.3 o superiore, sono testate fino a PHP 8.4, sono in congelamento delle funzionalità e passano alla sola sicurezza dal 23 novembre 2026, con fine vita indicata a novembre 2027. Il progetto ha annunciato una nuova versione principale della linea Yii 2 con PHP 8.3 come requisito minimo. Chi sceglie Yii 2 oggi deve quindi mettere in conto un ulteriore aggiornamento a breve.
E Yii3?
Yii3 è stato rilasciato alla fine del 2025, richiede PHP 8.2 o superiore ed è organizzato in pacchetti indipendenti, ciascuno con la propria versione, che seguono gli standard PSR. Secondo il calendario del progetto ha l’orizzonte di supporto più lungo, con la fine vita indicata al 2035. È però un framework diverso sia da Yii 1.1 sia da Yii 2: per un’applicazione 1.1 significa comunque una riscrittura, con un costo paragonabile a quello di una migrazione a Yii 2 o a un altro framework moderno come Symfony o Laravel.
Come scegliere
La scelta dipende da quanto deve vivere ancora l’applicazione e da quanto lavoro si può affrontare nei prossimi mesi. Queste sono le indicazioni che diamo di solito:
- Se l’applicazione è su PHP 5.x o 7.x, il primo passo è quasi sempre aggiornare Yii alla 1.1.32 e portarla su PHP 8.3 o 8.4. Costa poco rispetto a una riscrittura e chiude il problema più urgente, il PHP senza patch.
- Se l’applicazione deve vivere ancora molti anni, la migrazione va pianificata subito dopo, verso Yii3 o verso un altro framework moderno, valutando anche le competenze del team che la manterrà.
- Se l’applicazione verrà dismessa entro due o tre anni, l’aggiornamento del ramo con un PHP supportato è spesso sufficiente, con un piano per correggere in proprio eventuali vulnerabilità del framework.
- Se la produzione è esposta e non può aspettare, la protezione del server viene prima di tutto, con il backport delle patch di sicurezza sul PHP in uso fino al rilascio sulla nuova versione.
Se hai un’applicazione Yii 1.1 e vuoi capire quale strada è realistica, contattaci indicando la versione di Yii, quella di PHP e il sistema operativo del server.
Per concludere
Yii 1.1 arriva a fine vita il 31 dicembre 2026, ma negli ultimi anni il ramo è stato adattato fino a PHP 8.4, con la versione 1.1.32 di dicembre 2025, mentre il supporto per PHP 8.5 è in sviluppo. Per molte applicazioni il passo più conveniente è aggiornare il framework all’ultima versione del ramo, rendere compatibile con PHP 8 il codice applicativo e le estensioni, e portare la produzione su PHP 8.3 o 8.4. Questo chiude il rischio più urgente e dà due o tre anni di tempo. Per le applicazioni destinate a durare serve poi una migrazione vera, che verso Yii 2, Yii3 o un altro framework moderno è comunque una riscrittura: Yii 2.0 entra in sola sicurezza a novembre 2026, mentre Yii3, rilasciato alla fine del 2025, offre l’orizzonte di supporto più lungo.