La 2.4.0 è uscita in general availability il 28 luglio, e nelle ultime settimane l’ho installata e stressata su un paio di ambienti di staging per capire cosa comporta davvero il salto. Non parlo di release notes: parlo di cosa succede quando provi a metterla in piedi e a farci girare un progetto reale. La sintesi è che questa non è una minor qualsiasi. È la release che sposta l’asticella dei requisiti infrastrutturali, e chi la sottovaluta rischia di scoprirlo in produzione.
Elasticsearch non è più opzionale
Il cambiamento più pesante, e quello che secondo me viene raccontato peggio, è che Elasticsearch diventa il motore di ricerca del catalogo obbligatorio anche su Magento Open Source. Fino alla 2.3 potevi cavartela con il search MySQL di default: brutto, lento sui cataloghi grandi, ma c’era. Nella 2.4.0 quel motore è stato rimosso. Se non hai un’istanza Elasticsearch raggiungibile e configurata, l’installer si ferma. Non è un warning, è un blocco.
La versione richiesta è Elasticsearch 7.x. Provando l’upgrade su un ambiente che girava con una 6.x mi sono trovato a dover aggiornare prima il cluster di ricerca e poi Magento, perché la 7 introduce breaking change lato mapping. Tradotto in pratica: se oggi hai un merchant su un hosting condiviso o su una VPS minimale senza Elasticsearch, la 2.4.0 non ci gira e basta. Serve un servizio in più da installare, monitorare, tenere aggiornato e proteggere (Elasticsearch esposto senza autenticazione è un problema di security reale, l’ho visto succedere).
La mia opinione: è la scelta tecnicamente giusta. Il search MySQL era un peso morto e nessun progetto serio lo usava già dal 2018. Ma spostare un componente da opzionale a obbligatorio in una release significa che il costo infrastrutturale del “Magento base” è appena salito, e questo cambia il conto economico dei progetti piccoli.
Two-Factor Authentication attivo di default
La seconda novità che tocchi con mano al primo login è che la 2FA sull’Admin è ora obbligatoria e attiva di serie. Installi, vai su /admin, e prima di fare qualsiasi cosa ti trovi la schermata di configurazione dell’autenticatore (Google Authenticator, Authy, U2F). Non è disattivabile dall’interfaccia con un flag: puoi solo disabilitarla via CLI o config, e sconsiglio caldamente di farlo.
Qui vedo già arrivare le prime richieste di supporto, perché cambia il modo in cui lavorano le agenzie. Se hai un team che entra nel backoffice di un cliente con un utente condiviso, la 2FA legata al singolo dispositivo ti costringe a ripensare gli accessi. È il momento buono per smettere di condividere credenziali, ma preparati alla frizione: su un progetto ho dovuto spiegare al cliente perché “l’admin ora chiede il telefono” e configurare l’autenticatore per tre persone diverse. Considerando la mole di attacchi bruteforce che vedo nei log di qualsiasi Magento esposto, questa è una delle poche imposizioni che difendo senza riserve.
I nuovi requisiti di hosting, in concreto
Al di là dei due titoloni, la 2.4.0 aggiorna tutto lo stack sotto il cofano, e qui si gioca la vera pianificazione dell’upgrade. Quello che ho verificato provandola:
- PHP 7.4 è la versione supportata di riferimento. La 7.1 e 7.2 sono fuori, e il codice della 2.4 usa costrutti che sulle versioni vecchie non girano. Se il tuo merchant è ancora su 7.2, l’upgrade PHP è un progetto a sé, con il rischio di estensioni che si rompono.
- Elasticsearch 7.6+, come detto, come componente a sé stante.
- MySQL 8.0 come target (MariaDB 10.4 lato compatibile). Anche qui, chi viene da MySQL 5.7 deve mettere in conto un aggiornamento del database engine.
- Composer 1.x per la gestione dei pacchetti, con l’autenticazione al repo Adobe da riconfigurare.
Il punto che voglio far passare è che nessuno di questi componenti si aggiorna “da solo” durante l’upgrade di Magento. PHP, MySQL ed Elasticsearch sono pezzi dell’infrastruttura che vanno portati avanti prima, in modo coordinato. Su un ambiente gestito bene è mezza giornata di lavoro; su un hosting improvvisato diventa la classica catena di sorprese dove aggiorni una cosa e se ne rompe un’altra.
Cosa si rompe: estensioni e temi
Questa è la parte che mi fa dire a tutti di non correre. Un cambio di minor version in Magento, storicamente, non è mai indolore per le estensioni di terze parti, e la 2.4.0 non fa eccezione. Provando a montare uno stack realistico su staging ho trovato diversi moduli che, dichiarati “compatibili 2.3”, davano errori di dependency injection o si appoggiavano a metodi deprecati poi rimossi.
Il rischio maggiore lo vedo su tre fronti:
- Moduli legati al search: qualsiasi estensione che estendeva o rimpiazzava il vecchio motore MySQL va verificata riga per riga, perché il layer sottostante è cambiato.
- Moduli di sicurezza/login: alcuni entrano in conflitto con la nuova 2FA nativa.
- Temi e customizzazioni frontend che toccano la barra di ricerca o i risultati: cambiando il backend di search, il comportamento e a volte il markup dei risultati si spostano.
Il messaggio pratico è banale ma lo ripeto: la 2.4.0 va provata su un ambiente di staging identico alla produzione prima di anche solo pensare al go-live. Il conto vero di un upgrade Magento non è mai il core, sono le estensioni.
Chi dovrebbe aggiornare subito e chi aspettare
Qui mi sbilancio, perché è la domanda che mi stanno facendo tutti in questi giorni.
Aggiorna presto (nel giro di poche settimane) se: stai partendo con un progetto nuovo, oppure hai già Elasticsearch, PHP 7.4 e un parco estensioni contenuto e ben mantenuto. In questi casi non ha senso costruire su una 2.3 che è già la generazione precedente: parti direttamente sulla 2.4.
Aspetta una minor (la prossima patch della serie 2.4) se: hai un merchant in produzione con decine di estensioni di terze parti, customizzazioni frontend pesanti, o un’infrastruttura ancora su PHP 7.2 / MySQL 5.7. Una versione .0 è, per definizione, quella dove emergono i primi assestamenti; su progetti critici preferisco far assorbire l’onda ai pionieri e muovermi quando i vendor delle estensioni hanno rilasciato i loro fix. Non è pigrizia, è gestione del rischio: un catalogo che non risponde perché Elasticsearch è mal configurato costa più di qualche settimana di attesa.
La linea che seguo con i progetti che gestisco è semplice: pianificare l’upgrade adesso, eseguirlo dopo aver validato lo stack e le estensioni su staging. La 2.4.0 non è una release da rimandare a tempo indefinito, perché è chiaro dove sta andando la piattaforma. Ma è esattamente il tipo di release che punisce chi la installa in fretta il venerdì pomeriggio.
In sintesi
La 2.4.0 alza l’asticella dell’infrastruttura: Elasticsearch obbligatorio, 2FA di serie, stack PHP/MySQL aggiornato. Sono scelte che condivido sul piano tecnico, ma che spostano in alto il costo di ingresso e rendono l’upgrade un progetto infrastrutturale, non un semplice bin/magento setup:upgrade. Chi ha l’ambiente già moderno può muoversi presto; chi ha estensioni e customizzazioni in produzione faccia il piano ora ed esegua dopo aver testato tutto su staging.
Mini-FAQ
Magento 2.4.0 funziona senza Elasticsearch?
No. Dalla 2.4.0 il motore di ricerca MySQL è stato rimosso ed Elasticsearch 7.x è un requisito obbligatorio, anche su Magento Open Source. Senza un’istanza configurata l’installazione si blocca.
La 2FA nell’Admin si può disattivare?
È attiva di default e non disabilitabile dall’interfaccia. Si può disattivare solo via CLI o configurazione, ma è fortemente sconsigliato: protegge il backoffice da attacchi bruteforce molto comuni.
Quali sono i requisiti minimi di hosting per Magento 2.4.0?
In pratica: PHP 7.4, MySQL 8.0 (o MariaDB 10.4), Elasticsearch 7.6+ e Composer. I componenti dell’infrastruttura vanno aggiornati prima di Magento, in modo coordinato.
Conviene aggiornare subito alla 2.4.0?
Dipende dal progetto. Progetti nuovi o con stack già moderno: sì, meglio partire direttamente sulla 2.4. Merchant in produzione con molte estensioni di terze parti o infrastruttura datata: pianificare ora, ma eseguire dopo aver validato estensioni e stack su un ambiente di staging identico alla produzione.
Sono Fabio Canovi, mi occupo di Magento e Adobe Commerce dal 2011 e sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconto quello che vedo dal campo lavorando su progetti e-commerce reali, senza filtri di marketing.