Extensie-audit voor een upgrade: Magento-technical debt verminderen

De meeste Magento-upgrades lopen niet vast op de corecode van Adobe. Ze lopen vast op een betaalmodule die sinds 2022 niemand meer heeft bijgewerkt, een thema dat een core-template overschrijft, of drie extensies die allemaal dezelfde class herschrijven. Elke module van derden die je meeneemt in een upgrade, moet worden gecontroleerd, bijgewerkt of gepatcht.

Een extensie-audit voor de upgrade maakt van die onbekende factor een lijst met eigenaren en besluiten. Deze gids loopt door de aanpak die wij aanraden: inventarisatie, gebruikscheck, compatibiliteitscheck, conflictcheck en daarna verwijderen.

Waarom de upgrades naar 2.4.8 en 2.4.9 meer op het spel zetten

Beide recente releases veranderden onderdelen van het platform waar extensies van afhankelijk zijn:

• 2.4.8 (april 2025) voegde compatibiliteit met PHP 8.4 toe, schrapte PHP 8.1, zette zoeken over naar OpenSearch en is niet meer compatibel met Elasticsearch. Ook werden diverse Laminas-afhankelijkheden vervangen.
• 2.4.9 (mei 2026) voegt ondersteuning voor PHP 8.5 toe en laat PHP 8.2 en 8.3 vallen. De releasenotes van Adobe beschrijven een eigen MVC-implementatie die Laminas MVC vervangt, de Symfony Cache-component die Zend_Cache vervangt en de WYSIWYG-editor die overstapt van TinyMCE naar HugeRTE.

Elke extensie die die libraries rechtstreeks aanroept, een eigen Elasticsearch-adapter meelevert of de editor aanpast, verdient aandacht. Ook de supporttermijnen zetten druk: het lifecyclebeleid van Adobe noemt 11 augustus 2026 als einde van de standaardondersteuning voor 2.4.6 en 31 mei 2027 voor 2.4.7.

Stap 1: maak een volledige module-inventaris

Begin met wat Magento als geïnstalleerd en ingeschakeld ziet:

bin/magento module:status --enabled  > modules-enabled.txt
bin/magento module:status --disabled > modules-disabled.txt

Maak daarna een lijst van wat Composer direct heeft geïnstalleerd, met versies en omschrijvingen:

composer show --direct
composer show --direct --format=json > composer-direct.json

Zoek tot slot de code die buiten Composer staat:

ls app/code/*/

Zet alles in één spreadsheet. Filter Magento_* coremodules en de meegeleverde pakketten van Adobe eruit, en voeg kolommen toe voor leverancier, geïnstalleerde versie, nieuwste versie, bron (Composer of app/code), eigenaar binnen het bedrijf en een besluit: behouden, updaten, vervangen of verwijderen.

Stap 2: vind ongebruikte en verlaten extensies

Ongebruikt

Uitgeschakelde modules zijn de makkelijke winst. Staat iets al maanden uit en mist niemand het, plan dan de verwijdering. Zoek bij ingeschakelde modules naar bewijs van echt gebruik:

• Is de functie zichtbaar op de storefront of in een dagelijkse workflow in de admin? Vraag het de mensen die de webshop runnen.
• Bevatten de databasetabellen recente rijen?
• Verschijnt de cronjob in cron_schedule en doet die nuttig werk?
• Staat de functie uit in de configuratie terwijl de module ingeschakeld blijft?

# Tables created by a vendor, with row counts
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name LIKE 'vendorprefix_%';

# Is the module's cron running?
SELECT job_code, status, MAX(executed_at)
FROM cron_schedule WHERE job_code LIKE 'vendorprefix_%'
GROUP BY job_code, status;

Verlaten of niet meer onderhouden

composer outdated --direct
composer audit

composer outdated toont welke pakketten nieuwere versies hebben en markeert pakketten die als abandoned zijn aangemerkt. composer audit controleert de geïnstalleerde versies op bekende security advisories. Bekijk per extensie ook de changelog van de leverancier en de datum van de laatste release. Een module zonder release die je beoogde PHP-versie ondersteunt, is een kandidaat voor vervanging.

Stap 3: controleer de compatibiliteit met de doelversie

Composer-constraints

Vraag Composer wat de upgrade blokkeert voordat je iets verandert:

composer why-not magento/product-community-edition 2.4.9
composer why-not php 8.4

Gebruik magento/product-enterprise-edition voor Adobe Commerce. De output toont elk pakket waarvan de constraints conflicteren met de doelversie. Die lijst is je upgrade-backlog.

Upgrade Compatibility Tool (Adobe Commerce)

De Upgrade Compatibility Tool (UCT) van Adobe analyseert de modules en corecode van een installatie tegen een doelversie en rapporteert kritieke problemen, fouten en waarschuwingen. Volgens de documentatie van Adobe is hij alleen beschikbaar voor Adobe Commerce-installaties, en je installeert hem vanaf repo.magento.com:

composer create-project magento/upgrade-compatibility-tool uct --repository https://repo.magento.com
chmod +x ./uct/bin/uct

# Check custom code against a target version
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9

# Only show new problems introduced by the upgrade
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9 \
  --ignore-current-version-compatibility-issues --min-issue-level=error

# Find modified core files
./uct/bin/uct core:code:changes /var/www/magento /path/to/vanilla

Controleer voordat je op het rapport vertrouwt of je UCT-versie de doelrelease ondersteunt waartegen je controleert.

Controle van de PHP-versie (Open Source en Commerce)

Draai op Magento Open Source, of als aanvulling op UCT, een statische PHP-compatibiliteitsscan met PHP_CodeSniffer en de PHPCompatibility-standaard over de code van derden:

vendor/bin/phpcs -p --standard=PHPCompatibility \
  --runtime-set testVersion 8.4- app/code vendor/vendorname

Controleer of de PHPCompatibility-versie die je installeert sniffs heeft voor je beoogde PHP-versie. Statische scans missen runtimeproblemen, dus draai de webshop ook op de beoogde PHP-versie op de stagingomgeving, met logging van deprecations aan.

Veelvoorkomende bevindingen bij de overstap naar PHP 8.4 zijn impliciet nullable parameters zoals function foo(Bar $bar = null), die in PHP 8.4 deprecated zijn ten gunste van ?Bar $bar = null. PHP 8.5 voegt meer deprecations toe, zoals de niet-canonieke casts (integer) en (boolean) en het gebruik van null als array-offset.

Stap 4: vind conflicten tussen plugins en preferences

Preferences vervangen een core-class volledig, dus maar één module kan winnen. Around-plugins op drukke codepaden kunnen elkaar breken en de webshop vertragen. Zet ze op een rij:

# Preferences declared by third-party code
grep -rn "<preference" app/code vendor/*/*/etc --include=di.xml | grep -v "vendor/magento"

# Full DI picture for a class that several modules touch
bin/magento dev:di:info "Magento\Checkout\Model\ShippingInformationManagement"

dev:di:info toont de actieve preference, de constructorargumenten en elke plugin op de class met het type (before, after, around). Markeer elke core-class met preferences van meer dan één leverancier, en elke class met meerdere around-plugins. Dat zijn de eerste plekken om na de upgrade te testen.

Zoek ook naar template- en layout-overrides van corebestanden in je thema. Een aangepast core-template breekt de build niet, maar kan ongemerkt nieuwe markup, CSP-nonces of beveiligingsfixes laten wegvallen.

Stap 5: vervang extensies door corefuncties

Sommige extensies zijn gekocht om gaten te vullen die Magento inmiddels zelf heeft gedicht. Typische voorbeelden die je moet nagaan:

Vervangen gaat niet vanzelf. Vergelijk functies, migreer data en train gebruikers opnieuw, maar elke module die je schrapt, is één afhankelijkheid minder bij elke toekomstige upgrade.

Stap 6: verwijder extensies veilig

1. Maak een back-up van de database en de code.
2. Schakel eerst uit op de stagingomgeving en voer een volledige regressietest uit: checkout, betalingen, orders aanmaken in de admin, imports en integraties.
3. Controleer welke data je moet bewaren, zoals maatwerkattributen, ordervelden of klantdata die de module heeft opgeslagen.
4. Verwijder de code. Voor modules die via Composer zijn geïnstalleerd:

bin/magento maintenance:enable
bin/magento module:disable Vendor_Module
composer remove vendor/module-package
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento maintenance:disable

Alternatief: bin/magento module:uninstall Vendor_Module --backup-db voert composer remove voor je uit en voert, met --remove-data, ook de eigen uninstall-routine van de module uit. Dit werkt alleen voor modules die via Composer zijn geïnstalleerd. Voor modules in app/codeschakel je ze uit, verwijder je de map en draai je daarna setup:upgrade.

5. Ruim restanten op, zorgvuldig: verweesde tabellen, core_config_data records en EAV-attributen. Verwijder data pas nadat de eigenaar binnen het bedrijf akkoord heeft gegeven.
6. Zet het live in productie als aparte release, vóór de platformupgrade, zodat je problemen uit elkaar kunt houden.

Veelgestelde vragen

Is de Upgrade Compatibility Tool beschikbaar voor Magento Open Source?

Nee. Volgens de documentatie van Adobe is de Upgrade Compatibility Tool alleen beschikbaar voor Adobe Commerce-installaties. Open Source-projecten kunnen Composer why-not, PHPCompatibility-scans en een testupgrade op de stagingomgeving combineren.

Moet ik een ongebruikte extensie uitschakelen of verwijderen?

Verwijderen. Een uitgeschakelde module staat nog steeds in je codebase, kan nog steeds botsen met Composer-constraints en heeft nog steeds updates nodig als de afhankelijkheden veranderen.

Hoe lang duurt een extensie-audit?

Dat hangt af van hoeveel modules van derden je draait en hoe goed ze gedocumenteerd zijn. De inventarisatie zelf gaat snel met de commando's hierboven. De tijd zit in de gebruikschecks met het bedrijf en het testen van vervangers.

Kunnen we PHP en Magento tegelijk upgraden?

Controleer de ondersteunde combinaties voor jouw upgradepad. 2.4.8 vereist PHP 8.3 of 8.4 voor productiegebruik, en 2.4.9 ondersteunt PHP 8.5 volledig, met PHP 8.4 alleen toegestaan voor upgradedoeleinden. Veel teams stappen over naar de beoogde Magento-versie op een PHP-versie die beide releases ondersteunen, en wisselen daarna in een aparte stap van PHP.

Bronnen

• Releasenotes Adobe Commerce 2.4.8
• Release notes van Adobe Commerce 2.4.9
• Adobe Experience League: uitgebrachte versies
• Adobe Experience League: lifecyclebeleid voor software
• Adobe Experience League: overzicht van de Upgrade Compatibility Tool
• Adobe Experience League: de Upgrade Compatibility Tool uitvoeren
• Adobe Experience League: bin/magento CLI-referentie
• Adobe Experience League: modules verwijderen
• Adobe Developer: configuratie van dependency injection
• PHP-handleiding: deprecated functies in PHP 8.4
• PHP-handleiding: deprecated functies in PHP 8.5