La 2.4.4 è uscita il 12 aprile, e in questi giorni sto facendo quello che faccio a ogni release importante: apro un ambiente di staging, ci monto sopra un progetto reale e guardo cosa si rompe. Stavolta si rompe parecchio. Non perché la release sia fatta male, anzi. Ma perché questa è la versione che chiude i conti con un pezzo di storia tecnica di Magento, e quando chiudi i conti qualcuno paga il saldo.
Lavoro su questa piattaforma dal 2011, dai tempi di Magento 1, e ho visto passare diverse migrazioni scomode. Questa la metto tra le più impegnative degli ultimi anni. Provo a spiegare perché, e soprattutto cosa farne se gestite un negozio in produzione oggi.
Cosa porta davvero la 2.4.4
Le voci di changelog sono tante, ma i tre pilastri che cambiano la vita a chi mantiene il codice sono questi.
PHP 8.1 (e addio alle versioni vecchie)
La 2.4.4 supporta ufficialmente PHP 8.1, oltre a PHP 7.4 e 8.0. È la prima release Magento a girare su 8.1, e non è un dettaglio da nota a piè di pagina. PHP 8.1 introduce novità di linguaggio (enum, readonly properties, fibers) ma soprattutto irrigidisce comportamenti che prima passavano lisci: deprecation più aggressive, gestione più severa dei tipi nullable, cambiamenti su come vengono trattate alcune funzioni interne. Il codice che “funzionava lo stesso” su 7.4 spesso su 8.1 emette warning o si pianta.
Il punto pratico: chi è ancora su PHP 7.3 o 7.4 non ha più molto spazio per rimandare. La finestra di supporto si stringe, e restare indietro sulla versione di PHP è il modo più silenzioso per accumulare debito tecnico e problemi di sicurezza.
La sostituzione di Zend Framework con Laminas
Questo è il cuore dell’upgrade, e il motivo per cui lo chiamo impegnativo. Il vecchio Zend Framework, su cui Magento poggiava da sempre per una lunga serie di componenti (mail, validazione, feed, HTTP, e altro), è ufficialmente end-of-life. Adobe ha completato la migrazione a Laminas, il progetto che ha raccolto l’eredità di Zend sotto la Linux Foundation.
Sul piano funzionale, Laminas è in gran parte un rename: le classi Zend_* e i namespace Zend\ diventano Laminas\. Ma proprio qui sta il problema. Ogni estensione, ogni modulo custom, ogni pezzo di integrazione che referenzia direttamente una classe Zend va toccato. E vi assicuro che nei progetti veri, quelli con anni di stratificazioni, i riferimenti a Zend sono ovunque: un modulo di fatturazione elettronica qui, un connettore verso un ERP là, una vecchia libreria di validazione custom che nessuno ricorda più di aver scritto.
In un progetto enterprise su cui sto lavorando, la migrazione a 2.4.4 non è fallita sul core Magento. È fallita su tre estensioni di terze parti che ancora chiamavano Zend_ a mano, e su un modulo custom scritto nel 2018 che nessuno aveva più aggiornato. Il core stava benissimo. Era tutto il resto a non essere pronto.
Nuovo storefront PWA e supporto esteso
Sul fronte frontend, la 2.4.4 porta avanti il lavoro su PWA Studio e sul nuovo storefront headless: è la direzione dichiarata di Adobe, e questa release consolida i pezzi dell’esperienza composable. Non è ancora la destinazione per tutti i merchant, ma è il segnale di dove va la piattaforma.
C’è poi un aspetto che i team tecnici sottovalutano e i CFO invece adorano: la 2.4.4 è una release con supporto esteso. Tradotto, riceverà patch di sicurezza e qualità per un orizzonte più lungo rispetto alle release intermedie. Se dovete scegliere dove atterrare con una migrazione che costa comunque fatica, atterrare su una versione con supporto lungo significa non doverla rifare tra sei mesi.
Perché è l’upgrade più impegnativo degli ultimi tempi
La mia tesi è semplice: la 2.4.4 non è difficile per quello che aggiunge, ma per quello che rimuove. Un aggiornamento che introduce funzionalità le puoi ignorare. Un aggiornamento che elimina le fondamenta su cui poggiava mezzo ecosistema di estensioni, no.
La combinazione PHP 8.1 più Laminas colpisce esattamente il punto più fragile di qualsiasi installazione Magento reale: il codice di terze parti. Il core lo aggiorna Adobe. Le vostre venti estensioni installate no, le aggiorna il rispettivo vendor, e solo quando ha voglia di farlo. Nei giorni successivi a una release così, il collo di bottiglia non è mai Magento: è aspettare che ogni fornitore di estensioni pubblichi la versione compatibile. Chi ha molto codice custom e molte estensioni commerciali installate è chi soffre di più.
Detto onestamente, questo è anche un bene. Trascinarsi dietro Zend a tempo indeterminato non era sostenibile, e la pulizia andava fatta. Ma va gestita come un progetto vero, non come un composer update lanciato di venerdì pomeriggio.
Chi dovrebbe aggiornare subito e chi aspettare
Non c’è una risposta unica, e diffido di chi ve la dà. Ecco come ragiono io, caso per caso.
Aggiornate presto se:
- Siete su una versione ormai fuori supporto (2.3.x o 2.4.x datate), e la sicurezza è un problema aperto: qui l’attesa costa più della migrazione.
- Avete poco codice custom e poche estensioni di terze parti: meno superficie da sistemare, migrazione relativamente lineare.
- Volete atterrare su una release con supporto esteso e non rimetterci mano a breve.
- Avete un ambiente di staging serio e un team che può testare a fondo prima di andare live.
Aspettate (ma pianificate) se:
- Il vostro negozio dipende da estensioni commerciali critiche che non hanno ancora dichiarato la compatibilità con 2.4.4: aggiornare prima dei vostri vendor significa portarsi a casa il loro debito.
- Avete molto codice legacy con riferimenti diretti a Zend: serve un audit del codice prima, non durante.
- Siete in piena stagione di picco commerciale: non si migra il motore mentre l’auto corre in autostrada.
La cosa che non consiglio a nessuno è la terza via: restare fermi e far finta di niente. Aspettare che una o due estensioni chiave si allineino è legittimo. Ignorare la 2.4.4 per un anno perché “tanto ora funziona” significa solo rendere la migrazione futura più dolorosa, non meno.
Come mi muoverei, in pratica
Il mio ordine di operazioni: prima un audit delle estensioni installate, vendor per vendor, per capire chi è già compatibile 2.4.4 e chi no. Poi un grep del codebase alla ricerca di ogni riferimento residuo a Zend nel custom. Poi un ambiente di staging su PHP 8.1, dove far girare i test e clickare i flussi che contano davvero: checkout, pagamento, ordine, sincronizzazione con l’ERP. Solo dopo si parla di data del go-live. La migrazione tecnica è la parte facile; la parte difficile è avere il coraggio di dire “non siamo pronti” quando i test lo dicono.
Mini-FAQ
La 2.4.4 richiede obbligatoriamente PHP 8.1?
No. La 2.4.4 supporta PHP 7.4, 8.0 e 8.1. Ma 8.1 è la novità della release ed è la direzione consigliata: restare su 7.4 significa avvicinarsi di nuovo alla fine del supporto.
Cos’è Laminas e perché sostituisce Zend?
Laminas è il successore ufficiale di Zend Framework, ormai end-of-life, mantenuto sotto la Linux Foundation. La 2.4.4 completa la sostituzione: le classi Zend_* diventano Laminas\*, e ogni codice che referenzia Zend direttamente va aggiornato.
Le mie estensioni si romperanno con la 2.4.4?
Dipende. Quelle mantenute e già aggiornate dal vendor no. Quelle vecchie o con riferimenti diretti a Zend sì. Prima di migrare, verificate con ogni fornitore la compatibilità dichiarata con 2.4.4.
Conviene aggiornare subito?
Se siete fuori supporto o avete poco codice custom, sì. Se dipendete da estensioni critiche non ancora compatibili, aspettate che si allineino, ma pianificate la migrazione da adesso.
Chi scrive — Fabio Canovi lavora su Magento e Adobe Commerce dal 2011, dai tempi di Magento 1. Tra i primi in Italia a ottenere la certificazione Adobe Commerce, progetta e mantiene installazioni Adobe Commerce e Magento Open Source per merchant mid-market ed enterprise.