Magento 2.4.9 voor developers: de features die ertoe doen

Adobe Commerce en Magento Open Source 2.4.9 (uitgebracht op 12 mei 2026) is de grootste 2.4.x-release in jaren, met meer dan 500 opgeloste issues en een serieuze stap richting platformmodernisering. Terwijl Google Pay Vault en de nieuwe betaalopties de meeste aandacht krijgen van merchants, zijn de wijzigingen voor developers minstens zo belangrijk. In dit artikel lopen we door de features die je codebase raken, met praktische voorbeelden.

PHP 8.4 en 8.5 support, PHP 8.2 vervalt

De meest ingrijpende wijziging is de runtime-baseline. PHP 8.2 wordt niet langer ondersteund. De core, de dependencies en de tooling draaien nu schoon op PHP 8.3, 8.4 en het gloednieuwe 8.5. De Braintree-extensie is specifiek bijgewerkt om PHP 8.5 te ondersteunen, met behoud van 8.4-compatibiliteit.

Voor je eigen modules betekent dit dat je de constraint in composer.json aanpast voordat je upgradet:

{
    "name": "ten50/module-catalog",
    "require": {
        "php": "~8.3.0 || ~8.4.0 || ~8.5.0",
        "magento/framework": "*"
    }
}

PHP 8.4 markeert daarnaast impliciet nullable parameters als deprecated, een veelvoorkomende bron van warnings in oudere Magento-modules. De fix is mechanisch, maar makkelijk over het hoofd te zien in een grote codebase:

public function getProductBySku(?string $sku = null): ?ProductInterface
{
    if ($sku === null) {
        return null;
    }
 
    return $this->productRepository->get($sku);
}

Draai een statische analyse met PHP 8.4 als target voordat je naar productie gaat. PHPStan en de meegeleverde bin/magento dev:-tooling brengen de impliciete nullables en de wijzigingen in typedeclaraties uit de Symfony-upgrade (hieronder beschreven) aan het licht.

Nieuwe GraphQL mutations voor headless storefronts

Draai je een headless of PWA-storefront, dan dicht 2.4.9 een aantal hardnekkige gaten in het GraphQL-schema. De clearCart mutation, voorheen alleen in Adobe Commerce, is nu ook beschikbaar in Open Source, en een nieuwe clearWishlist mutation ondersteunt bulk-verwijdering in een enkele call in plaats van een loop over losse items:

mutation ClearWishlist {
  clearWishlist(wishlistId: "1") {
    wishlist {
      id
      items_count
      items_v2 {
        items {
          id
        }
      }
    }
  }
}

Die ene round trip vervangt het oude patroon waarbij je elk wishlist-item ophaalde en per id een removeProductsFromWishlist mutation afvuurde, wat merkbaar was bij accounts met grote lijsten.

Token exchange voor single sign-on

De nieuwe exchangeExternalCustomerToken mutation is de blikvanger voor integrators. Hij authenticeert een klant met een integratietoken en geeft in een enkele response zowel het customer token als de klantgegevens terug. Dit is precies wat je nodig hebt wanneer een externe identity provider of een parent-platform de gebruiker al heeft geauthenticeerd en je hem een ingelogde storefront-sessie wilt geven zonder een tweede login:

mutation ExchangeToken($token: String!) {
  exchangeExternalCustomerToken(token: $token) {
    customer_token
    customer {
      firstname
      lastname
      email
    }
  }
}

Je neemt het teruggegeven customer_token en zet dat als Authorization: Bearer-header op volgende requests. Geen brosse workarounds meer met admin-integratietokens of custom resolvers om een externe login in Magento te bruggen.

Ordertotalen exclusief btw

Een kleine maar veelgevraagde toevoeging: het OrderTotal-type stelt nu grand_total_excl_tax beschikbaar. Tot nu toe moest je het nettototaal client-side reconstrueren uit grand_total en de btw-opbouw, wat foutgevoelig was bij gemengde btw-tarieven. Nu is het een volwaardig veld:

query CustomerOrders {
  customer {
    orders {
      items {
        number
        total {
          grand_total {
            value
            currency
          }
          grand_total_excl_tax {
            value
            currency
          }
          total_tax {
            value
            currency
          }
        }
      }
    }
  }
}

Voor B2B-storefronts die overal nettoprijzen tonen, verdwijnt hiermee een hele klasse afrondingsbugs.

Frameworkmodernisering: Symfony 7.4 LTS en Symfony Cache

Onder de motorkap zijn alle Symfony-dependencies bijgewerkt naar de Symfony LTS 7.4-lijn, en het deprecated Zend_Cache-component is eindelijk vervangen door het Symfony Cache-component. Voor de meeste webshops is dit onzichtbaar, maar twee groepen maatwerkcode verdienen aandacht.

Ten eerste kan elke klasse die een Symfony-core class extend, bijgewerkte typedeclaraties en method-signatures nodig hebben om aan te sluiten op de nieuwe versies. Ten tweede breekt code die direct met Zend_Cache praat. De juiste aanpak is de framework-abstractie te gebruiken, die de migratie gewoon overleeft:

namespace Ten50\Module\Service;
 
use Magento\Framework\App\CacheInterface;
use Magento\Framework\Serialize\SerializerInterface;
 
class CatalogFeedCache
{
    private const CACHE_KEY = 'ten50_catalog_feed';
    private const CACHE_LIFETIME = 3600;
 
    public function __construct(
        private readonly CacheInterface $cache,
        private readonly SerializerInterface $serializer
    ) {}
 
    public function get(): ?array
    {
        $cached = $this->cache->load(self::CACHE_KEY);
 
        return $cached ? $this->serializer->unserialize($cached) : null;
    }
 
    public function save(array $feed): void
    {
        $this->cache->save(
            $this->serializer->serialize($feed),
            self::CACHE_KEY,
            ['catalog'],
            self::CACHE_LIFETIME
        );
    }
}

Grep je codebase op Zend_Cache en vervang direct gebruik door CacheInterface voordat je upgradet. De serializer-dependency is net zo belangrijk: serialize()/unserialize() op ruwe objecten werd al afgeraden, en de schonere cache-laag maakt dit een goed moment om dat op te ruimen.

Wat dit betekent voor je upgrade

Magento 2.4.9 is meer een moderniseringsrelease dan een feature-release. De betaaltoevoegingen helpen je checkout, maar het echte werk voor ontwikkelteams is de sprong naar PHP 8.4/8.5 en de Symfony-migratie. Plan een upgrade in drie stappen: verhoog je module-constraints en draai statische analyse op PHP 8.4, spoor direct gebruik van Zend_Cache op, en adopteer de nieuwe GraphQL mutations waar ze je storefront vereenvoudigen. In die volgorde verloopt de upgrade soepel en eindig je op een platform dat ruim in het PHP 8.5-tijdperk ondersteund blijft.