La 2.4.4 è uscita ad aprile, e a distanza di qualche mese posso finalmente scrivere qualcosa che non sia una previsione da changelog. Ho portato in produzione questa versione su alcuni progetti reali — merchant diversi per dimensione e maturità tecnica — e ho preso appunti su cosa è andato liscio, cosa mi ha fatto perdere giornate intere e cosa, con il senno di poi, imposterei diversamente. Non è una release come le altre: il salto a PHP 8.1 e il passaggio da Zend Framework a Laminas la rendono, secondo me, l’upgrade più impegnativo degli ultimi anni.
Perché la 2.4.4 non è un aggiornamento “di routine”
Chi arriva da una 2.4.3 pensando a un update incrementale rimane sorpreso. Qui ci sono due cambiamenti che toccano le fondamenta del codice, e vanno capiti prima di aprire il terminale.
Il primo è PHP 8.1. Non è solo un numero di versione più alto: 8.1 stringe le viti su cose che prima passavano silenziosamente. Le dynamic properties, i tipi di ritorno, le funzioni deprecate. Codice custom che girava benissimo su 7.4 comincia a generare deprecation notice a raffica, e alcune estensioni terze semplicemente si rompono.
Il secondo è il passaggio a Laminas. Adobe ha completato la migrazione dalle vecchie librerie Zend Framework — ormai a fine vita — ai componenti Laminas. Sulla carta è una sostituzione quasi uno-a-uno. Nella pratica, ogni pezzo di codice che richiama ancora una classe Zend_ va toccato a mano.
La mia opinione netta: la 2.4.4 va trattata come un progetto di migrazione, non come una patch. Chi la schedula come “una serata di lavoro” arriva a metà strada e si blocca.
Le estensioni che mi hanno dato problemi
Qui è dove ho bruciato più tempo. Provo a raggruppare i casi che ho visto ripetersi, così se state pianificando l’upgrade sapete dove guardare per primi.
Moduli fermi a Zend Framework
Il pattern più frequente. Estensioni — spesso di vendor minori o sviluppate su misura anni fa — che istanziavano ancora Zend_Mail, Zend_Pdf o helper di validazione Zend. Su un merchant fashion di taglia media avevo un modulo custom per la generazione delle fatture PDF che si è semplicemente rifiutato di partire. Riscrivere i richiami verso Laminas non è complesso, ma va fatto file per file, e senza test automatici non te ne accorgi finché un cliente non prova a scaricare una fattura.
Incompatibilità con PHP 8.1
Il secondo grande gruppo. Estensioni che passano array dove 8.1 si aspetta un tipo preciso, oppure che si appoggiano a proprietà dinamiche. Alcuni vendor seri avevano già rilasciato versioni compatibili — bene per loro — ma diversi moduli di nicchia erano ancora indietro. In un caso ho dovuto forkare un modulo di gestione feed marketplace e sistemarlo io, perché il vendor non aveva ancora una release 8.1-ready.
Componenti usciti dal core
Attenzione a questo, perché non è un bug ma una scelta di Adobe che spiazza. Diversi bundled extension che prima trovavi nel core — alcune integrazioni di pagamento e marketing di terze parti — sono state spostate sul Commerce Marketplace e non arrivano più “di serie”. Se il vostro checkout dipendeva da uno di questi moduli dato per scontato, dopo l’upgrade ve lo ritrovate mancante. Su un progetto l’ho scoperto in staging, per fortuna, e non in produzione.
Contorno: jQuery, Composer, Elasticsearch
La 2.4.4 aggiorna anche jQuery e alza i requisiti su Composer ed Elasticsearch. Il tema è che ogni personalizzazione JavaScript basata su API jQuery vecchie va verificata. Non l’ho trovato drammatico, ma è l’ennesima casella da spuntare che allunga la checklist.
I test che servono davvero
Se c’è una cosa che questa migrazione mi ha insegnato è che il testing manuale a campione non basta. Ecco cosa ha ripagato il tempo investito.
- Checkout end-to-end con ogni payment method attivo. È il flusso che paga lo stipendio del merchant. Ogni metodo di pagamento va provato fino alla conferma d’ordine, non fino alla pagina di riepilogo.
- Scansione delle deprecation di PHP 8.1. Girare il sito con il logging dei deprecation attivo e leggere davvero l’output. È noioso, ma è lì che si nascondono i problemi che esplodono tre settimane dopo.
- Grep del codice custom e dei moduli per le classi
Zend_. Una ricerca banale su tutto il codebase vi dice in mezz’ora quanto lavoro Laminas vi aspetta. - Verifica dei processi asincroni: generazione PDF, export, cron, code di indicizzazione. Sono le aree meno visibili e quindi meno testate, ma è dove Zend e PHP 8.1 fanno più danni.
- MFTF sui percorsi critici. Dove esistevano già test funzionali, li ho fatti girare a ogni step. Dove non c’erano, il costo di scriverli si è ripagato solo sui flussi core.
I tempi reali
Parliamo di numeri, perché è la domanda che mi fanno tutti. Non do una formula magica, ma un ordine di grandezza dai progetti che ho seguito.
Su un’installazione relativamente pulita, poche estensioni terze e codice custom ordinato, la migrazione tecnica si chiude in pochi giorni-uomo. Su un’installazione stratificata negli anni, con decine di moduli e custom accumulato, si arriva tranquillamente a diverse settimane, e la parte pesante non è aggiornare Magento: è sistemare le estensioni e il codice custom perché tornino verdi su PHP 8.1 e Laminas. Il codice di Adobe si aggiorna da sé. Il vostro no.
La mia stima onesta: preventivate almeno il doppio del tempo che assegnereste a un upgrade minore, e tenete un buffer per l’estensione che scoprirete rotta all’ultimo.
Cosa rifarei e cosa no
Cosa rifarei: partire sempre da un audit delle estensioni prima ancora di toccare la versione. Aprire la lista dei moduli, controllare vendor per vendor quali hanno una release compatibile 8.1 e quali no, e trasformare quella lista nella vera roadmap dell’upgrade. Questo mi ha risparmiato le sorprese peggiori.
Cosa non rifarei: sottovalutare i processi in background. Sul primo progetto mi sono concentrato sul front-end e sul checkout, e ho pagato dazio su un flusso di export ordini che nessuno guardava mai finché non ha smesso di funzionare. Ora quei processi li metto in cima alla checklist, non in fondo.
Un’ultima cosa che non rifarei: rimandare. So che è controintuitivo con una release così impegnativa, ma il salto a PHP 8.1 e Laminas non diventa più facile aspettando. Ogni mese di rinvio è un mese di codice nuovo scritto sulla base vecchia, cioè più debito da ripagare quando l’upgrade sarà comunque inevitabile.
In sintesi
La 2.4.4 è una release che divide chi ha una base di codice sana da chi ha accumulato debito. Non è cattiva — anzi, PHP 8.1 e Laminas sono la direzione giusta e ci liberano da librerie a fine vita. Ma è esigente, e chi la affronta con leggerezza se ne accorge in produzione, che è il posto peggiore per accorgersene.
Domande frequenti
La 2.4.4 richiede PHP 8.1?
Supporta PHP 8.1 ed è il salto che rende l’upgrade impegnativo. Il codice custom e le estensioni che giravano su PHP 7.4 vanno verificati per le deprecation e le incompatibilità introdotte da 8.1.
Perché le mie estensioni si rompono dopo l’upgrade alla 2.4.4?
Le due cause più frequenti sono i moduli che richiamano ancora le vecchie classi Zend Framework — sostituite da Laminas — e il codice non compatibile con PHP 8.1. Un terzo caso è dato dai componenti terzi usciti dal core e spostati sul Marketplace.
Quanto tempo serve per migrare alla 2.4.4?
Dipende dallo stato del codebase. Un’installazione pulita si chiude in pochi giorni-uomo; una stratificata può richiedere diverse settimane, con la maggior parte del tempo speso a rendere estensioni e codice custom compatibili con PHP 8.1 e Laminas, non ad aggiornare Adobe Commerce in sé.
Da dove conviene partire?
Da un audit delle estensioni installate, vendor per vendor, per capire quali hanno una release compatibile con PHP 8.1 e quali no. Quella lista è la vera roadmap dell’upgrade.
Chi sono — Sono Fabio Canovi, mi occupo di Magento e Adobe Commerce dal 2011. Ho progettato e gestito soluzioni e-commerce enterprise su questa piattaforma e sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconto quello che vedo dal campo, con opinioni esplicite e casi reali resi anonimi.