PHP 8.6 e Magento 2: cosa cambia davvero per sviluppatori e merchant

descrive il logo di magento 2 e di php 8.6

PHP continua il suo ciclo di evoluzione annuale e PHP 8.6 rappresenta il prossimo passo della piattaforma su cui si basa gran parte dell’ecosistema ecommerce.

Al momento della scrittura PHP 8.6 è ancora in fase Beta e la release stabile è prevista per novembre 2026. Non è quindi una versione da installare oggi su un ambiente Magento di produzione.

È però il momento giusto per iniziare a valutarne l’impatto.

Per Magento il passaggio a una nuova versione di PHP non riguarda infatti soltanto il core della piattaforma. Bisogna considerare almeno quattro livelli:

PHP → Magento → moduli di terze parti → codice custom

Ed è spesso negli ultimi due che emergono i problemi maggiori durante un upgrade.

Magento 2 supporta già PHP 8.6?

No.

Le attuali versioni della linea Magento Open Source / Adobe Commerce 2.4.8 supportano PHP 8.3 e PHP 8.4.

Questo significa che, anche se fosse tecnicamente possibile avviare Magento utilizzando PHP 8.6, una configurazione del genere non dovrebbe essere utilizzata in produzione fino al supporto ufficiale da parte di Adobe.

Il punto interessante è quindi un altro: quanto sarà complesso portare un progetto Magento esistente verso PHP 8.6 quando il supporto ufficiale arriverà?

La risposta dipenderà soprattutto dalla qualità del codice e delle estensioni installate.

Le novità di PHP 8.6

PHP 8.6 non sembra essere una release rivoluzionaria dal punto di vista sintattico. Prosegue piuttosto il percorso iniziato dalle precedenti versioni PHP 8.x: maggiore type safety, API più coerenti, controlli più rigorosi e progressiva eliminazione di comportamenti legacy.

Per Magento questo è particolarmente importante.

Magento è infatti un’applicazione PHP molto grande, fortemente object oriented e basata su Dependency Injection, Reflection, generated code, plugin, interceptor e un numero elevato di librerie Composer.

Piccole variazioni nel comportamento del linguaggio possono quindi avere effetti molto più evidenti rispetto a una normale applicazione PHP.

Partial Function Application

Una delle novità più interessanti di PHP 8.6 è la Partial Function Application.

Permette di creare callable partendo da funzioni o metodi esistenti lasciando alcuni argomenti da specificare successivamente.

Concettualmente permette di trasformare codice simile a:

$calculate = fn ($price) => calculateDiscount($price, 20);

in una forma nella quale PHP può costruire direttamente una funzione parzialmente applicata.

Per Magento non significa che dovremo improvvisamente riscrivere Service, Repository o ViewModel.

Può però risultare interessante nel codice applicativo che utilizza pipeline di trasformazione, collection processing, import/export o elaborazioni di catalogo.

Il beneficio principale è soprattutto una maggiore espressività del linguaggio.

clamp(): piccola funzione, molti casi d’uso ecommerce

PHP 8.6 introduce la funzione:

clamp($value, $min, $max);

che limita un valore all’interno di un intervallo.

Ad esempio:

$qty = clamp($requestedQty, 1, 100);

restituisce sempre un valore compreso tra 1 e 100.

In un progetto Magento situazioni di questo tipo sono frequenti:

$discount = max(0, min($discount, 100));

potrà diventare:

$discount = clamp($discount, 0, 100);

Possibili applicazioni riguardano quantità, percentuali di sconto, scoring, soglie, valori calcolati durante importazioni e normalizzazione di dati provenienti da sistemi esterni.

Non cambia l’architettura di Magento, ma rende più leggibile codice che oggi viene frequentemente implementato attraverso combinazioni di min() e max().

Nuovo enum SortDirection

PHP 8.6 introduce inoltre:

SortDirection::Ascending
SortDirection::Descending

La novità è interessante per Magento perché ordinamenti e collection sono presenti praticamente ovunque.

Nel codice Magento siamo abituati a valori come:

$collection->setOrder('created_at', 'DESC');

oppure a costanti e stringhe utilizzate per rappresentare ASC e DESC.

Il nuovo enum non sostituirà automaticamente le API Magento esistenti, ma rappresenta bene la direzione che PHP sta prendendo: ridurre progressivamente l’utilizzo di stringhe “magiche” in favore di costrutti tipizzati.

È un principio che vale anche nello sviluppo dei nuovi moduli Magento.

Readonly sempre più maturo

PHP 8.6 continua inoltre l’evoluzione delle proprietà readonly.

Per chi sviluppa Magento questo è interessante soprattutto nella costruzione di:

  • DTO;
  • Value Object;
  • command;
  • query object;
  • oggetti utilizzati nelle integrazioni;
  • strutture dati immutabili.

Un DTO moderno può essere molto più semplice rispetto alle classiche classi PHP utilizzate storicamente nell’ecosistema Magento.

Ad esempio:

final readonly class ProductData
{
    public function __construct(
        public string $sku,
        public string $name,
        public float $price
    ) {}
}

L’evoluzione del linguaggio rende sempre meno necessario scrivere grandi quantità di codice puramente infrastrutturale.

Miglioramenti alle Closure

PHP 8.6 introduce anche ottimizzazioni relative alle Closure.

È un cambiamento particolarmente interessante dal punto di vista delle performance, anche se non bisogna aspettarsi automaticamente un Magento “più veloce” semplicemente cambiando runtime.

Magento e le librerie che lo circondano fanno però largo uso di callback, Closure e callable.

Ogni miglioramento dell’engine in quest’area può quindi avere effetti interessanti soprattutto su applicazioni PHP molto grandi e con un numero elevato di operazioni per request.

La reale entità del miglioramento dovrà comunque essere misurata con benchmark Magento specifici.

Migliore gestione degli errori JSON

PHP 8.6 migliora anche le informazioni restituite quando json_decode() incontra JSON non valido, indicando con maggiore precisione dove si trova l’errore.

Può sembrare un dettaglio, ma in Magento il JSON è ovunque.

Pensiamo a:

  • REST API;
  • GraphQL;
  • webhook;
  • configurazioni;
  • integrazioni ERP;
  • marketplace;
  • sistemi PIM;
  • feed;
  • code e sistemi asincroni.

Quando un sistema esterno invia payload molto grandi, sapere semplicemente che esiste un “Syntax error” non è particolarmente utile.

Una diagnostica più precisa può ridurre sensibilmente il tempo necessario per identificare payload malformati.

Il vero problema: le deprecazioni

La parte più importante di PHP 8.6 per un progetto Magento probabilmente non saranno le nuove feature.

Saranno le deprecazioni.

È una dinamica che abbiamo già visto durante le migrazioni:

PHP 7.4 → PHP 8.1 → PHP 8.2 → PHP 8.3 → PHP 8.4.

PHP sta diventando progressivamente più rigoroso e numerosi comportamenti storicamente tollerati vengono prima deprecati e successivamente eliminati.

Questo rappresenta un problema soprattutto per estensioni Magento datate.

Un’installazione Magento moderna può contenere decine di moduli provenienti da vendor differenti e migliaia di classi PHP custom.

Il fatto che il core Magento sia compatibile con una nuova versione di PHP non significa automaticamente che lo sia l’intero progetto.

Il problema delle estensioni Magento

Supponiamo di avere:

Magento / Adobe Commerce
│
├── Magento Core
├── Hyvä
├── Payment Provider
├── ERP Connector
├── Shipping Module
├── Search Module
├── Marketing Module
├── Feed Module
└── Custom Modules

Per dichiarare realmente un progetto compatibile con PHP 8.6 dobbiamo verificare tutti questi componenti.

Ed esiste un ulteriore livello:

Magento module
      ↓
Composer package
      ↓
Third-party library

Un modulo apparentemente compatibile potrebbe dipendere da una libreria che non lo è.

Per questo la verifica deve partire da Composer ma non può fermarsi a Composer.

Composer sarà il primo controllo

Quando Magento supporterà ufficialmente PHP 8.6, uno dei primi test da effettuare sarà:

composer why-not php 8.6

Il comando permette di individuare quali package impediscono l’utilizzo della nuova versione.

Potremmo trovare, ad esempio:

vendor/module-x
requires php ~8.2.0 || ~8.3.0

In questo caso il problema potrebbe non essere neppure il codice.

Il modulo potrebbe funzionare perfettamente con PHP 8.6, ma il relativo composer.json non permetterne l’installazione.

È una situazione molto comune durante gli upgrade Magento.

Static analysis prima dell’upgrade

Aspettare di aggiornare PHP in produzione per scoprire i problemi è l’approccio peggiore.

Una strategia migliore consiste nell’analizzare preventivamente il progetto con strumenti come:

PHPStan
PHP_CodeSniffer
PHPCompatibility
Composer
Magento Coding Standard

e successivamente eseguire test automatici sull’intero progetto.

L’obiettivo dovrebbe essere trasformare l’upgrade PHP da un’attività esplorativa a un processo verificabile.

Attenzione al rumore delle deprecazioni

Un altro problema tipico delle nuove versioni PHP è il numero di warning e deprecation generati da codice legacy.

In produzione possono avere conseguenze indirette.

Se vengono registrati migliaia di messaggi:

PHP Deprecated: ...
PHP Deprecated: ...
PHP Deprecated: ...

il problema non è soltanto estetico.

Può aumentare:

  • I/O su disco;
  • dimensione dei log;
  • traffico verso sistemi di logging centralizzati;
  • utilizzo CPU;
  • costi di observability;
  • difficoltà nell’individuare errori realmente importanti.

In sistemi Magento con traffico elevato una singola deprecation eseguita molte volte per request può trasformarsi rapidamente in milioni di righe di log.

PHP 8.6 renderà Magento più veloce?

È troppo presto per dirlo.

E soprattutto bisogna distinguere due concetti:

performance del runtime PHP

e

performance dell’applicazione Magento.

Magento dipende da molti altri componenti:

Browser
   ↓
CDN / Varnish
   ↓
Nginx
   ↓
PHP-FPM
   ↓
Magento
   ↓
Redis / Valkey
   ↓
MariaDB
   ↓
OpenSearch

Ridurre del 5% il tempo di esecuzione PHP non significa necessariamente ridurre del 5% il tempo di risposta percepito dall’utente.

Una request potrebbe trascorrere gran parte del proprio tempo aspettando MariaDB, Redis, OpenSearch o un servizio esterno.

Per questo i benchmark seri dovranno misurare almeno:

PHP 8.4 + Magento
vs
PHP 8.5 + Magento
vs
PHP 8.6 + Magento

utilizzando lo stesso database, dataset, configurazione PHP-FPM, cache e infrastruttura.

Quando aggiornare Magento a PHP 8.6?

Non appena PHP 8.6 sarà pubblicato?

No.

Il momento corretto sarà quando la propria versione Magento supporterà ufficialmente PHP 8.6 e l’intero stack applicativo sarà stato verificato.

La sequenza corretta dovrebbe essere:

PHP 8.6 Stable
        ↓
Supporto ufficiale Magento
        ↓
Verifica Composer dependencies
        ↓
Aggiornamento moduli
        ↓
Static analysis
        ↓
Unit / Integration tests
        ↓
Functional / E2E tests
        ↓
Staging
        ↓
Performance test
        ↓
Produzione

Saltare direttamente dal primo all’ultimo punto significa trasformare un normale aggiornamento tecnologico in un’attività ad alto rischio.

Conclusioni

PHP 8.6 non rivoluziona il modo in cui svilupperemo Magento 2, ma continua un processo molto più importante: la modernizzazione progressiva del linguaggio PHP.

Type safety, readonly objects, enum, API più coerenti, controlli più rigorosi e miglioramenti dell’engine stanno lentamente cambiando anche il modo in cui dovrebbe essere scritto il codice Magento.

Per chi gestisce installazioni Magento complesse il punto fondamentale, però, rimane un altro.

La compatibilità con una nuova versione PHP non è una proprietà di Magento: è una proprietà dell’intero progetto.

Core, moduli, librerie Composer, integrazioni e codice custom devono essere considerati come un unico sistema.

Per questo PHP 8.6 non è ancora qualcosa da installare sui server Magento di produzione.

È invece qualcosa che vale già la pena iniziare a testare nelle pipeline di sviluppo.

Perché il momento migliore per trovare un’incompatibilità con la prossima versione PHP non è durante l’upgrade.

È diversi mesi prima.

FAQ — PHP 8.6 e Magento 2

Magento 2 supporta già PHP 8.6?

No. Al momento PHP 8.6 non fa parte delle configurazioni ufficialmente supportate da Adobe Commerce o Magento Open Source.

Adobe Commerce 2.4.9 supporta ufficialmente PHP 8.5, mentre la linea 2.4.8 supporta PHP 8.3 e PHP 8.4.

Posso installare Magento 2 su PHP 8.6?

Tecnicamente è possibile iniziare a sperimentare con PHP 8.6 in ambienti di sviluppo, ma non è una configurazione da utilizzare in produzione.

Anche nel caso in cui Magento riesca ad avviarsi correttamente, potrebbero esserci incompatibilità nel core, nei moduli di terze parti o nelle dipendenze Composer.

È quindi opportuno attendere il supporto ufficiale da parte di Adobe.

Magento 2.4.8 sarà compatibile con PHP 8.6?

Attualmente Magento/Adobe Commerce 2.4.8 supporta PHP 8.3 e PHP 8.4.

Non è quindi possibile considerare PHP 8.6 una configurazione supportata per Magento 2.4.8.

Qual è la versione PHP supportata da Magento 2.4.9?

Adobe Commerce 2.4.9 supporta ufficialmente PHP 8.5.

PHP 8.4 è consentito da Adobe per il processo di upgrade, ma non è raccomandato come runtime di produzione per la versione 2.4.9.

Come posso verificare se un progetto Magento è pronto per PHP 8.6?

Un primo controllo può essere effettuato attraverso Composer:

composer why-not php 8.6

Questo permette di individuare le dipendenze che dichiarano un requisito PHP incompatibile.

Il controllo dovrebbe poi essere completato attraverso static analysis e test automatici utilizzando strumenti come PHPStan, PHP_CodeSniffer, PHPCompatibility, PHPUnit e test E2E.

Se Magento Core è compatibile con PHP 8.6, anche i moduli lo saranno?

Non necessariamente.

La compatibilità deve essere verificata sull’intero stack applicativo:

PHP
 ↓
Magento Core
 ↓
Moduli di terze parti
 ↓
Moduli custom
 ↓
Dipendenze Composer

Un singolo package non aggiornato può impedire l’upgrade oppure generare errori durante l’esecuzione.

PHP 8.6 renderà Magento più veloce?

Non necessariamente.

Gli eventuali miglioramenti del runtime PHP devono essere misurati nel contesto dell’intera architettura Magento.

Database, OpenSearch, Redis/Valkey, Varnish, servizi esterni e codice applicativo possono incidere sulle performance molto più del runtime PHP stesso.

Saranno quindi necessari benchmark specifici prima di poter quantificare eventuali vantaggi prestazionali.

Conviene prepararsi già adesso a PHP 8.6?

Sì, soprattutto per progetti Magento complessi.

Non significa utilizzare PHP 8.6 in produzione, ma mantenere aggiornate le dipendenze, eliminare codice deprecato, migliorare la copertura dei test e verificare periodicamente la compatibilità dei moduli.

In questo modo il futuro upgrade diventa un’attività pianificabile invece di un intervento emergenziale.

Fonti e approfondimenti

Per approfondire PHP 8.6 e la compatibilità con Magento consigliamo principalmente le fonti ufficiali PHP e Adobe.

PHP

Magento / Adobe Commerce

Tool per verificare la compatibilità

Nota: PHP 8.6 è ancora in fase di sviluppo. Funzionalità, deprecazioni e dettagli implementativi possono cambiare prima della release stabile. Prima di qualsiasi aggiornamento di un ambiente Magento di produzione è necessario verificare i System Requirements ufficiali Adobe e la compatibilità di tutte le estensioni installate.

Articoli correlati