La 2.4.7 è uscita il 9 aprile 2024, ed è una di quelle release che a leggere il changelog sembrano “manutenzione” e invece spostano il piano di lavoro dei prossimi mesi. Non ci sono feature spettacolari da mettere in una slide, ma ci sono due o tre cose che decidono se la tua piattaforma resta supportata o inizia a invecchiare. Provo a raccontartela come la spiego a chi mi chiede “vale la pena?” — senza changelog copiato, con le cose che contano davvero quando poi tocca fare l’upgrade.
PHP 8.3: il vero motivo per cui questa release esiste
La notizia principale della 2.4.7 è il supporto a PHP 8.3. La release resta compatibile anche con PHP 8.2, che però ha una End of Support fissata a fine 2025: dopo quella data chi gira su 2.4.7 dovrebbe passare a 8.3. Core, extension bundled e servizi SaaS di Adobe sono già allineati a 8.3.
Detto onestamente, questo è il motivo per cui la maggior parte dei merchant che seguo aggiorna. Non lo fanno per una feature, lo fanno perché rimanere su una versione di PHP che va in end of life significa esporsi su un layer — il linguaggio stesso — dove non vuoi avere debito tecnico. Ho visto progetti restare fermi a versioni vecchie “perché tanto funziona”, e il problema non è mai il giorno in cui decidi di aggiornare: è il giorno in cui una vulnerabilità ti obbliga a farlo di corsa, con la libreria di terze parti che non è compatibile e il fornitore che non risponde.
Sul contorno requisiti la 2.4.7 continua la strada già tracciata: Composer 2.7, OpenSearch 2.x come motore di ricerca di riferimento (Elasticsearch 7.17 ancora accettato, ma è una coda che si accorcia), MariaDB 10.6 / MySQL 8.0, Redis 7, RabbitMQ aggiornato. Le librerie JavaScript, le dipendenze NPM e l’intero stack Laminas sono stati portati alle versioni compatibili con 8.3. Tradotto: non è un aggiornamento che fai “solo su Magento”, è un aggiornamento che tocca l’infrastruttura sotto. Chi pianifica l’upgrade guardando solo alla versione del core sottostima sempre la parte più costosa.
GraphQL: la parte che interessa a chi va headless
Se stai andando verso un frontend disaccoppiato — e sempre più merchant mid-market lo stanno facendo — la sezione GraphQL della 2.4.7 è quella da leggere con attenzione.
Due cose concrete. La prima: arriva la mutation createGuestCart, che sostituisce la deprecata createEmptyCart. Sembra un dettaglio da sviluppatori, ma risolve un problema reale: con la vecchia mutation non sapevi se il carrello fosse di un guest o di un utente loggato, e quella ambiguità in un flusso di checkout headless ti costa in complessità e in bug sottili.
La seconda, per me più importante: l’estensione della resolver cache. Più resolver GraphQL diventano cacheabili nella GraphQL Resolver Results cache, e questo si sente sulle query servite via POST. Sui frontend headless la latenza delle API è il collo di bottiglia percepito dall’utente, non il tempo di rendering. Ogni resolver che riesci a cacheare è un pezzo di TTFB che togli. È il tipo di miglioramento che non entra in una demo ma che sposta i Core Web Vitals di un progetto reale.
C’è anche più copertura GraphQL per i custom attribute, che è un’altra di quelle cose che sembrano marginali finché non ti servono: se hai un catalogo con attributi custom pesanti — e chi vende B2B ne ha sempre — poterli leggere via GraphQL senza estensioni artigianali fa la differenza tra un’integrazione pulita e una serie di workaround.
Coupon multipli, performance e shipping
La feature funzionale più visibile è la possibilità di applicare più coupon per ordine. C’è una nuova configurazione, “Maximum number of coupons per order”, di default impostata a 1 — quindi il comportamento storico resta invariato finché non decidi tu — e puoi gestire i coupon multipli sia via REST sia via GraphQL. Non è la rivoluzione del pricing, ma per chi fa campagne promozionali stratificate toglie un vincolo che prima costringeva a logiche custom fragili.
Sul fronte performance, la 2.4.7 migliora il caricamento delle product listing page per prodotti complessi con molte opzioni e la gestione degli indexer. Sono i due punti dove un catalogo grande soffre di più, quindi bene così.
Aggiornati anche i servizi FedEx e UPS alle API recenti dei carrier. E qui si collega la parte scomoda.
Le deprecazioni che possono romperti qualcosa
Questa è la sezione che salto mai quando valuto un upgrade, ed è quella che i changelog raccontano male. Nella 2.4.7:
- Le vecchie UPS XML API sono state rimosse dal core. Se la tua integrazione di spedizione poggia ancora su quelle, non è un warning: è codice che non c’è più.
- I moduli Temando sono stati rimossi dal core di Magento Open Source (erano deprecati dalla 2.4.4).
- Sono state aggiornate librerie e dipendenze che possono far emergere incompatibilità in extension di terze parti non mantenute.
Il mio consiglio operativo, dopo aver visto parecchi upgrade andare storti su questo punto: prima ancora di toccare l’ambiente, fai girare l’Upgrade Compatibility Tool e fatti dare dai fornitori delle extension la conferma scritta di compatibilità con 2.4.7 e PHP 8.3. Non la promessa a voce. Il costo vero di questa release non è nel core Adobe, che è solido — è nel long tail di moduli custom e di terze parti che nessuno ha più toccato da due anni. In un caso recente, su un merchant fashion di fascia media, il blocco non è stato Magento: è stato un modulo di gestione taglie mai aggiornato, con il fornitore sparito. L’upgrade tecnico era di due giorni; risolvere quel modulo ne è costati dieci.
Sicurezza: il punto che non ammette rinvii
La 2.4.7 include diversi security fix e introduce il rate limiting nativo sui dati di pagamento nelle API REST e GraphQL — una difesa in più contro gli attacchi di tipo carding, che sui merchant italiani vedo aumentare. Su Page Builder è stata sistemata la gestione dei custom style format ereditati da TinyMCE nelle versioni precedenti la 2.4.6, che ora tornano disponibili come atteso nel content type testo.
Sulla sicurezza la mia posizione è netta e non la cambio: la security è l’unica ragione che rende un upgrade non negoziabile. Le feature possono aspettare il budget del prossimo trimestre, una vulnerabilità su un e-commerce transazionale no.
Allora, aggiornare o no?
La mia lettura, senza giri di parole. Se sei su 2.4.5 o 2.4.6 e la 2.4.7 è già uscita, la domanda non è “se” ma “quando”, e la risposta ragionevole è “entro l’anno, pianificato bene”. Il driver è duplice: PHP 8.3 con l’orizzonte di fine supporto di 8.2, e la baseline di sicurezza. Se sei più indietro — 2.4.4 o precedenti — la 2.4.7 è la tappa giusta verso cui puntare, ma trattala come un progetto con test di regressione seri, non come un composer update del venerdì pomeriggio.
Se stai valutando il salto verso un’architettura più moderna, ne ho scritto parlando di headless e composable commerce e di quando ha senso spingere sul B2B: la 2.4.7, con GraphQL più maturo, è una buona base di partenza. E se ti interessa il quadro d’insieme delle direzioni di Adobe, l’ho raccontato in dove sta andando Adobe Commerce.
FAQ
Quando è stata rilasciata Adobe Commerce 2.4.7?
Il 9 aprile 2024, sia nella versione Adobe Commerce sia in Magento Open Source.
Adobe Commerce 2.4.7 richiede PHP 8.3?
No, non lo richiede ma lo supporta. La 2.4.7 gira sia su PHP 8.2 sia su 8.3. Poiché PHP 8.2 va in End of Support a fine 2025, conviene pianificare il passaggio a 8.3.
Cosa può rompersi aggiornando alla 2.4.7?
I punti critici sono le UPS XML API e i moduli Temando rimossi dal core, e le extension di terze parti non aggiornate a PHP 8.3. Un audit con l’Upgrade Compatibility Tool prima dell’upgrade evita brutte sorprese.
Chi sono — Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech. Lavoro su Magento e Adobe Commerce da oltre dieci anni e sono stato tra i primi in Italia a certificarmi su Adobe Commerce. Sono certificato anche su Adobe Experience Manager, Adobe Analytics e Adobe Target (Master – Target Architect). Su questo blog scrivo la mia lettura da insider di quello che succede nell’ecosistema Adobe e nell’e-commerce, senza filtri commerciali.