FCHEADERJSPLACEHOLDER

Adobe Commerce 2.4.5 in arrivo: cosa aspettarsi

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Fabio Canovi
Consulente Adobe · AI Specialist

Tra pochi giorni, il 9 agosto, arriva la General Availability di Adobe Commerce 2.4.5. Non è ancora installabile mentre scrivo, ma le release notes sono già leggibili e in questi giorni sto facendo quello che faccio prima di ogni minor release: leggermele con calma e capire cosa cambia davvero per i merchant che seguo. Lo scrivo perché ho notato che intorno a ogni nuova versione si crea sempre un po’ di rumore, tra chi la vive come un problema e chi non la considera affatto. La verità, come quasi sempre, sta nel mezzo.

Parto da una tesi, così mettiamo subito le carte in tavola: se sei già su 2.4.4, la 2.4.5 è uno degli aggiornamenti meno traumatici degli ultimi anni. Il grosso del lavoro pesante lo hai già fatto ad aprile. Provo a spiegare perché.

Cosa sappiamo della 2.4.5

La 2.4.5 è una minor release nella linea 2.4, e le release notes raccontano una storia abbastanza chiara. Ci sono tre blocchi di contenuto che mi interessano davvero.

Il primo sono i security fix. Adobe dichiara un pacchetto di correzioni di sicurezza incluse nella release, senza segnalazione di exploit attivi noti al momento dell’annuncio. È la parte che, dal mio punto di vista, rende la 2.4.5 non negoziabile nel medio periodo: gli aggiornamenti di sicurezza non sono un optional, sono la ragione principale per cui una piattaforma va tenuta in linea. Su questo non ho opinioni sfumate.

Il secondo blocco è la piattaforma applicativa. La 2.4.5 conferma il supporto a PHP 8.1 e mantiene PHP 8.0, con Composer 2.2. Sul contorno infrastrutturale si aggiornano le compatibilità: Elasticsearch 7.17, il supporto a OpenSearch come motore di ricerca, Redis 6.2, RabbitMQ 3.9, MariaDB nelle versioni testate. Nulla di sconvolgente, ma è esattamente il tipo di manutenzione che tiene lontano il debito tecnico.

Il terzo blocco sono i quality fix: diverse centinaia di correzioni funzionali distribuite su carrello, checkout, GraphQL, import/export, gestione delle immagini, PWA. Non fanno titolo, ma sono la parte che i team operativi apprezzano di più, perché chiudono bug con cui convivono da mesi.

Perché per chi è già su 2.4.4 cambia poco (in senso buono)

Qui sta il punto che voglio far passare. Il salto davvero impegnativo, quest’anno, è stato quello verso la 2.4.4 di aprile: è lì che è arrivato PHP 8.1, è lì che Composer è passato alla linea 2.2, è lì che sono cadute compatibilità storiche. Chi ha fatto quel passaggio ha già pagato il conto più salato, in termini di adeguamento del codice custom e delle estensioni di terze parti.

La 2.4.5 si appoggia sulla stessa base tecnologica. Non ti chiede di rifare la migrazione PHP, non ti ribalta il gestore delle dipendenze. Per un merchant già su 2.4.4 con un parco moduli ordinato, l’upgrade assomiglia più a un intervento di manutenzione programmata che a un progetto. Ho visto entrambe le situazioni sul campo: un merchant fashion nell’ordine dei ~15M di GMV, arrivato pulito su 2.4.4 in primavera, per il quale la 2.4.5 sarà una finestra di poche ore; e un retailer rimasto indietro di due minor, per il quale invece ogni aggiornamento diventa un cantiere perché il debito si è accumulato. La differenza non è la versione. È quanto sei rimasto in linea.

Detto onestamente, un contro-argomento esiste: “se cambia poco, perché muovermi ora?”. La mia risposta è che i security fix non aspettano la tua comodità, e che rimandare è proprio il meccanismo con cui un merchant scivola indietro di due o tre release e trasforma un intervento leggero nel cantiere di cui sopra. La 2.4.5 leggera è una conseguenza dell’essere stati diligenti prima. Non è un caso, è un metodo.

Come pianifico l’adozione

Non installo mai una minor release il giorno della GA in produzione, e non lo consiglio a nessuno. Il mio approccio, che applico anche alla 2.4.5, è banale ma disciplinato.

  1. Aspetto la GA e leggo le release notes definitive. Le note pre-rilascio danno il quadro, ma la lista puntuale dei fix e delle compatibilità va verificata sulla versione effettivamente rilasciata.
  2. Inventario delle estensioni. Prima ancora di toccare il core, controllo la compatibilità dei moduli di terze parti. È lì che si nascondono le sorprese, non nel codice Adobe.
  3. Upgrade su staging allineato alla produzione, con un giro completo di regression sui flussi che contano: catalogo, checkout, integrazioni ERP, pagamenti.
  4. Finestra di deploy concordata, con backup e piano di rollback pronto. Sul serio, non a parole.

Per un merchant già in linea su 2.4.4 questa sequenza si chiude in tempi ragionevoli. Il mio piano personale sui progetti che seguo è: raccolta note definitive nella settimana della GA, staging entro fine agosto, produzione a settembre dopo il rientro, lontano dai picchi di traffico. Nessuna fretta, nessun ritardo colpevole.

La mia posizione

La 2.4.5 non è una release che cambia le regole del gioco, e va benissimo così. È una release di consolidamento: sicurezza, manutenzione della piattaforma, qualità. Per me il valore di una minor come questa non si misura in feature nuove, ma in quanto ti aiuta a restare in una posizione da cui il prossimo aggiornamento sarà altrettanto indolore. Chi ha fatto bene i compiti con la 2.4.4 lo scoprirà da solo tra qualche settimana.

Domande rapide

Quando esce Adobe Commerce 2.4.5?
La General Availability è prevista per il 9 agosto 2022. Fino ad allora sono disponibili le release notes, ma la versione non è ancora installabile.

Devo rifare la migrazione a PHP 8.1 per passare a 2.4.5?
No, se sei già su 2.4.4. Il supporto a PHP 8.1 e Composer 2.2 è arrivato con la 2.4.4: la 2.4.5 si appoggia sulla stessa base, quindi non richiede di rifare quel salto.

La 2.4.5 è un aggiornamento obbligatorio?
Non nell’immediato, ma include security fix: nel medio periodo restare in linea con le release di sicurezza è la ragione principale per adottarla.

Quanto è complesso l’upgrade da 2.4.4 a 2.4.5?
Per un’installazione già su 2.4.4 con estensioni compatibili è un intervento di manutenzione, non un progetto. La complessità reale dipende dal codice custom e dai moduli di terze parti, non dal core.


Sono Fabio Canovi, mi occupo di Magento e Adobe Commerce da oltre dieci anni e sono tra i primi professionisti in Italia ad aver conseguito la certificazione Adobe Commerce. Su questo blog racconto, senza filtri, come leggo l’evoluzione della piattaforma e cosa significa per chi vende online.

Fabio Canovi imprenditore digitale nel settore e-Commerce in Italia.
Chi sono
Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech. Tra i primi in Italia certificato Adobe Commerce e certificato AEM, Analytics e Target (Master su Target). Negli ultimi due anni ho unito le competenze Adobe con l’AI agentica, lavorando con Claude Code e Cowork e costruendo MCP su misura per portare gli agenti dentro le piattaforme e-commerce reali.

Articoli correlati