Quando a fine luglio è uscita la 2.4.0, ho fatto quello che faccio con ogni major: l’ho installata su un ambiente di staging, l’ho rotta di proposito e ho preso appunti. Poi ho detto a più di un merchant, senza troppi giri di parole, di aspettare. Non perché la 2.4.0 fosse un brutto rilascio, tutt’altro: era il salto architetturale più netto degli ultimi anni. Ma proprio perché era un salto, la prima minor era il momento giusto per muoversi sul serio. Quella minor è arrivata il 15 ottobre. Si chiama Magento 2.4.1 ed è la prima vera occasione, secondo me, per chi aveva messo in pausa il piano di upgrade.
In questo pezzo vi racconto cosa porta davvero, perché la vedo come il momento in cui parte l’ondata di chi aveva aspettato, e come la sto affrontando con chi seguo.
Cosa cambia con la 2.4.1
Partiamo dal contesto, perché la 2.4.1 non si capisce senza la 2.4.0. La major di luglio aveva alzato l’asticella dei requisiti: Elasticsearch diventato obbligatorio per il catalog search, 2FA imposto sull’Admin, supporto a PHP 7.4 e MySQL 8.0, l’addio a Zend Framework in favore di Laminas, la nuova media gallery e diverse integrazioni core spostate su Marketplace. Roba che non si assorbe in un pomeriggio.
La 2.4.1 lavora su quella base e fa quello che una buona prima minor deve fare: consolidare. Ci sono centinaia di fix funzionali al core, buona parte dei quali arrivati dalla community attraverso pull request e issue risolte su GitHub. Non è un dettaglio da poco: è la conferma che il modello di sviluppo aperto, con i community engineering slot e i contributi esterni, sta producendo un core più stabile release dopo release. Quando leggo la lista dei fix riconosco problemi reali, quelli che ti fanno perdere ore in produzione, non voci di changelog messe lì per fare numero.
Sul fronte security, la 2.4.1 include un pacchetto di correzioni a vulnerabilità del core. Per me questo da solo giustifica la pianificazione dell’upgrade: restare su una versione precedente vuol dire accumulare debito di sicurezza, e su una piattaforma e-commerce il debito di sicurezza è la peggiore forma di debito tecnico che conosca.
Poi c’è la parte che mi interessa di più guardando avanti: GraphQL. La copertura continua ad allargarsi, e questo rilascio aggiunge supporto per aree che prima obbligavano a soluzioni ibride, tra cui funzionalità legate a gift card, gift registry, reward points e store credit sul lato Commerce, oltre a coperture utili anche su Open Source come related, up-sell e cross-sell products. Per chi sta guardando al headless e al PWA, ogni pezzo di GraphQL in più è un pezzo di custom development in meno. È lenta, questa costruzione, ma è nella direzione giusta.
Perché la vedo come il momento dei “temporeggiatori”
C’è un pattern che osservo a ogni ciclo di release, e la 2.4 non fa eccezione. Alla major escono gli early adopter, quelli che aggiornano per principio o perché hanno un team interno che se lo può permettere. Tutti gli altri aspettano. E fanno bene ad aspettare: una 2.4.0 con requisiti nuovi di zecca, su Elasticsearch obbligatorio e 2FA forzato, è esattamente il tipo di rilascio dove i primi ad arrivare fanno da collaudatori per tutti gli altri.
La prima minor cambia il calcolo. Con la 2.4.1 sul tavolo, chi aveva rimandato ha davanti una versione dove i problemi più ruvidi della major sono stati smussati, dove la community ha già segnalato e risolto una quantità importante di edge case, e dove i moduli e le estensioni di terze parti hanno avuto qualche mese per adeguarsi alla nuova base. Non è un caso che io stia ricevendo adesso le richieste di chi a luglio mi diceva “aspettiamo”.
Un esempio concreto, ovviamente anonimizzato. Un merchant fashion sul mid-market, catalogo ampio e picchi stagionali pesanti, a luglio era fermo su una 2.3. Il freno non era la voglia, era il rischio: cambiare motore di ricerca in piena stagione con la 2.4.0 appena uscita era una scommessa che nessuno con la testa sul collo avrebbe fatto. Con la 2.4.1 il ragionamento si ribalta. Elasticsearch non è più una novità da testare al buio, è una cosa che gira in produzione da mesi su tante installazioni, e questo abbassa il rischio percepito quanto quello reale.
La mia raccomandazione su upgrade e testing
Vengo alla parte pratica, quella che conta quando si smette di leggere e si apre il terminale.
- Se siete già su 2.4.0, aggiornate a 2.4.1 senza troppi ragionamenti. È una minor, il salto è contenuto, e i fix di security da soli valgono l’operazione. Testate, certo, ma è un aggiornamento a basso attrito.
- Se siete su 2.3.x, pianificate adesso il passaggio alla 2.4.1, non alla 2.4.0. Saltare direttamente alla minor più matura vi risparmia di fare da collaudatori. Il vero lavoro qui non è l’upgrade in sé, è il contorno: infrastruttura per Elasticsearch, compatibilità di PHP 7.4, revisione delle estensioni di terze parti e delle integrazioni core migrate su Marketplace.
- Trattate il testing come un progetto, non come un passaggio. Ambiente di staging che rispecchia la produzione, regression sul checkout, sul catalog search e sul processo d’ordine, verifica dei custom module uno per uno. Il punto dolente della 2.4 non è mai il core, sono le personalizzazioni accumulate negli anni che nessuno ha più il coraggio di toccare.
- Non aggiornate in alta stagione. Sembra ovvio, ma vedo ancora chi ci prova. Con i requisiti infrastrutturali della 2.4, un upgrade fatto di fretta a novembre è il modo migliore per rovinarsi il Black Friday.
La mia posizione, netta: la 2.4.1 è la release su cui consolidare per i prossimi mesi. Non aspettate la prossima minor sperando in una versione ancora più liscia. Quel ragionamento, portato all’estremo, non finisce mai, e nel frattempo il debito di sicurezza cresce. La finestra buona per muoversi è questa.
In sintesi
- Magento 2.4.1 è la prima minor della serie 2.4 e ha un ruolo di consolidamento della major di luglio.
- Porta centinaia di fix funzionali al core, molti di provenienza community, un pacchetto di correzioni di security e una copertura GraphQL più ampia.
- È il momento in cui molti merchant che avevano rimandato l’upgrade alla 2.4.0 iniziano a muoversi, perché il rischio della major si è ridotto.
- La raccomandazione: chi è su 2.4.0 aggiorni subito, chi è su 2.3.x pianifichi il passaggio direttamente alla 2.4.1, con testing serio e mai in alta stagione.
Domande frequenti
Conviene passare dalla 2.3 direttamente alla 2.4.1?
Sì. Puntare alla minor più matura invece che alla 2.4.0 fa evitare di fare da collaudatori dei problemi già risolti. Il grosso dello sforzo sta nell’infrastruttura e nella compatibilità delle personalizzazioni, non nel salto di versione in sé.
Quali sono i requisiti principali da considerare per la 2.4?
Elasticsearch obbligatorio per il catalog search, 2FA imposto sull’Admin, supporto a PHP 7.4 e MySQL 8.0, e diverse integrazioni core spostate su Marketplace. Sono questi, più che il codice, i punti che allungano i tempi di un upgrade.
La 2.4.1 introduce nuove funzionalità o solo fix?
Entrambe le cose. Oltre ai fix funzionali e di security, amplia la copertura GraphQL, un tassello importante per chi sta guardando a headless e PWA.
Posso aggiornare durante la stagione di picco?
Sconsigliato. Con i requisiti infrastrutturali della 2.4, un upgrade fatto in fretta durante l’alta stagione è un rischio che non vale la pena correre. Meglio pianificarlo in una finestra tranquilla.
Chi sono. Mi occupo di Magento e Adobe Commerce da anni, da quando nel 2011 ho iniziato a lavorare su Magento 1, e ho vissuto da vicino l’evoluzione della piattaforma release dopo release. 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 senza casi riconoscibili.