Zend Framework 1 è stato per anni una delle scelte più diffuse per gestionali, portali e applicazioni aziendali in PHP. Molte di quelle applicazioni sono ancora in produzione, spesso su PHP 5.x, e funzionano. Il framework però ha raggiunto la fine del supporto nel 2016, e il suo ultimo rilascio ufficiale è stato scritto per un PHP che oggi non riceve più patch da anni. Ogni tentativo di aggiornare PHP si scontra con il codice del framework prima ancora che con quello dell’applicazione.
Chi deve decidere cosa fare nel 2026 ha davanti tre strade: adottare un fork mantenuto dalla comunità che rende Zend Framework 1 compatibile con PHP 8, portare l’applicazione su Laminas MVC, oppure riscriverla per parti su un framework moderno. In questo articolo vediamo lo stato di ciascuna, cosa comporta in termini di lavoro e di orizzonte temporale, e come scegliere.
Zend Framework 1 oggi
Il repository ufficiale di Zend Framework 1 riporta che il progetto ha raggiunto la fine del supporto il 28 settembre 2016, con l’ultimo rilascio pubblico alla versione 1.12.20, e che il repository è archiviato in sola lettura. Da allora il codice originale non riceve correzioni di sicurezza né adattamenti alle nuove versioni di PHP.
Zend Framework 2, uscito nel 2012, era già un framework riscritto da zero, con un’architettura diversa e senza compatibilità con la versione 1. Le versioni 2 e 3 sono poi confluite nel progetto Laminas, che ne ha proseguito lo sviluppo con un nuovo nome e nuovi spazi dei nomi. Per un’applicazione ZF1, quindi, passare al “successore naturale” ha sempre richiesto una migrazione vera e propria.
Perché non esiste un aggiornamento diretto a Laminas
Laminas offre uno strumento di migrazione che riscrive automaticamente codice e configurazione da Zend Framework a Laminas. Copre le versioni 2 e 3, Expressive e Apigility, e lascia fuori Zend Framework 1. La ragione è strutturale, perché tra le due generazioni cambia quasi tutto:
- le classi di ZF1 usano nomi con il trattino basso, come
Zend_Controller_Action, mentre Laminas usa gli spazi dei nomi di PHP; - il ciclo della richiesta, i plugin del front controller e gli helper di azione non hanno un equivalente uno a uno;
- la configurazione, le dipendenze tra oggetti e il caricamento dei moduli seguono modelli diversi;
- componenti molto usati come
Zend_Db_Table,Zend_FormeZend_Registryhanno successori con interfacce diverse, oppure non ne hanno.
Passare da ZF1 a Laminas significa quindi riscrivere controller, configurazione e buona parte dello strato di presentazione, conservando soprattutto la logica di business e lo schema del database.
Strada 1: zf1-future, il fork della comunità
zf1-future è un fork di Zend Framework 1 mantenuto dalla comunità, con l’obiettivo dichiarato di far funzionare ZF1 con le versioni recenti di PHP. Mantiene i nomi delle classi e le interfacce del framework originale, e anche nel 2026 ha pubblicato nuove versioni, come la 1.25.2 di agosto, con correzioni di compatibilità. Secondo il README del progetto, è supportato e testato da PHP 7.4 a 8.3, mentre PHP 8.4 e 8.5 sono già nella suite di test ma non ancora supportati ufficialmente.
Si installa con Composer e prende il posto della vecchia cartella library/Zend:
# Installa il fork nel progetto (richiede PHP 7.4 o superiore)
composer require shardj/zf1-future
# Nel file di avvio, carica l’autoload di Composer prima di Zend_Application
# require __DIR__ . '/../vendor/autoload.php';
# Poi rimuovi la vecchia copia del framework dall’include_path
# e dal repository, per non caricare due versioni delle stesse classi
git rm -r library/ZendIl fork aggiorna soltanto il framework. Il codice dei controller, dei modelli e delle viste va comunque reso compatibile con PHP 8, con le stesse correzioni di qualunque altro progetto: funzioni rimosse, costruttori in stile PHP 4, proprietà dinamiche, nuovi confronti tra numeri e stringhe. Per trovarle in anticipo usiamo gli strumenti descritti nell’articolo sull’analisi statica per la migrazione.
È la strada più rapida e meno invasiva, e dà tempo. Ha un limite da mettere per iscritto: dipende da un gruppo di volontari, senza un calendario di supporto garantito. Va trattata come un modo per tenere l’applicazione su un PHP supportato mentre si decide il futuro, con un controllo periodico dello stato del progetto.
Strada 2: Laminas MVC
Laminas MVC è l’architettura più vicina a quella di ZF1: controller, azioni, moduli e viste. Sulla carta è la destinazione naturale. Nel 2025 però il comitato tecnico di Laminas ha deciso di ritirarla, e a marzo 2026 ha pubblicato il calendario di fine vita: i pacchetti di Laminas MVC ricevono solo correzioni di sicurezza fino al 31 dicembre 2028, termine del supporto di sicurezza di PHP 8.4, e non verranno adattati a PHP 8.5.
La decisione riguarda solo lo strato MVC. Mezzio e i componenti di Laminas, come validatori, filtri e accesso ai dati, restano in sviluppo attivo. Migrare oggi un’applicazione ZF1 su Laminas MVC vuol dire affrontare una riscrittura per arrivare a una piattaforma che ha già una data di fine, e che costringerà a una seconda migrazione entro pochi anni. Nella maggior parte dei casi non lo consigliamo.
Strada 3: riscrivere per parti, su Mezzio o su un altro framework
La terza strada è la migrazione progressiva, che il progetto Laminas stesso suggerisce per chi lascia MVC: il cosiddetto strangler fig pattern. La nuova applicazione nasce accanto alla vecchia, sullo stesso dominio e sullo stesso database. Un instradamento in testa, nel server web o in un piccolo strato PHP, decide quali percorsi servire con il codice nuovo e quali lasciare a ZF1. Una sezione alla volta, le funzioni passano alla nuova applicazione finché la vecchia non serve più.
Mezzio è la destinazione che Laminas raccomanda, basata su middleware e sugli standard PSR. Molte aziende scelgono invece Symfony o Laravel, per la disponibilità di sviluppatori e di pacchetti. Dal punto di vista della migrazione la differenza conta meno di quanto sembri: in tutti i casi si riscrivono controller e viste e si conservano logica di business e dati. Conta di più che i due mondi condividano autenticazione e sessione, perché l’utente non deve accorgersi di passare dall’uno all’altro.
Preparare il terreno dentro ZF1
Prima ancora di scegliere il framework di destinazione si può lavorare dentro l’applicazione esistente. La logica di business che oggi sta nei controller o nei modelli basati su Zend_Db_Table si sposta in classi PHP semplici, senza dipendenze dal framework, caricate con l’autoload di Composer. Quelle classi le usa subito ZF1 e domani le userà la nuova applicazione, senza riscriverle. Allo stesso modo la configurazione può uscire dai file .ini letti da Zend_Config e passare a variabili d’ambiente che entrambe le applicazioni sanno leggere.
Ogni passo di questo tipo si rilascia da solo, riduce la parte di codice legata a ZF1 e rende più breve, e più prevedibile, la riscrittura vera e propria. È anche il modo migliore per scoprire presto le dipendenze nascoste, come registri globali, variabili statiche e helper richiamati ovunque.
Come scegliere
Non esiste una risposta valida per tutti. Queste sono le domande che usiamo per orientare la decisione:
- Quanto deve vivere ancora l’applicazione? Se è destinata a essere sostituita entro due o tre anni, zf1-future con un PHP supportato è quasi sempre la scelta più ragionevole.
- Quanto è legata al framework? Un’applicazione con molta logica nei controller e nei form di ZF1 costa di più da riscrivere di una che usa ZF1 solo per instradamento e viste.
- Ci sono test automatici? Senza test, ogni strada richiede prima di costruire una rete di controlli sui percorsi critici.
- Chi la manterrà? Trovare sviluppatori che conoscono ZF1 è sempre più difficile; su Symfony, Laravel o Mezzio è più semplice.
- Che urgenza c’è sulla sicurezza? Se la produzione è su un PHP fuori supporto ed esposta su Internet, la priorità è proteggerla subito, qualunque strada si scelga.
Nella pratica la combinazione più frequente è la prima strada seguita dalla terza: zf1-future per portare subito l’applicazione su un PHP supportato, poi una riscrittura progressiva con calma, senza la pressione di un server vulnerabile.
Da dove partire
Il primo passo è sapere quali parti di Zend Framework 1 l’applicazione usa davvero. Un conteggio dei componenti citati nel codice dà un’idea immediata di quanto il progetto dipenda dal framework, e quindi di quanto costerebbe una riscrittura:
# Componenti di ZF1 usati dal codice applicativo, dal più citato
grep -rhoE --include='*.php' --include='*.phtml' 'Zend_[A-Za-z]+' application/ \
| sort | uniq -c | sort -rn | head -n 30
# Versione di ZF1 inclusa nel progetto
grep -h "const VERSION" library/Zend/Version.phpIl secondo passo riguarda la produzione. zf1-future richiede almeno PHP 7.4, quindi un’applicazione ferma su PHP 5.x deve comunque attraversare il lavoro sulle funzioni rimosse prima di poterlo adottare. Nel frattempo il server va protetto: è il caso tipico in cui il backport delle patch di sicurezza sul PHP in uso fa da ponte. Se vuoi una valutazione sulla tua applicazione, contattaci indicando la versione di ZF1 e di PHP.
In conclusione
Zend Framework 1 è fuori supporto dal 28 settembre 2016 e non ha un percorso di aggiornamento automatico verso Laminas, perché le due generazioni hanno architetture diverse. Le strade realistiche nel 2026 sono tre. zf1-future, il fork della comunità, porta il framework su PHP dal 7.4 all’8.3 con poco lavoro, ma dipende da volontari. Laminas MVC è l’architettura più simile, ma riceve solo correzioni di sicurezza fino al 31 dicembre 2028 e non supporterà PHP 8.5, quindi oggi la sconsigliamo. La riscrittura progressiva su Mezzio o su un altro framework moderno costa di più, ma si distribuisce nel tempo e porta a una piattaforma con un futuro lungo. Spesso conviene combinare la prima e la terza strada, proteggendo nel frattempo la produzione con il backport delle patch.
