Extension-Audit vor einem Upgrade: Magento-Altlasten abbauen

Die meisten Magento-Upgrades scheitern nicht an Adobes Core-Code. Sie scheitern an einem Zahlungsmodul, das seit 2022 niemand aktualisiert hat, an einem Theme-Override eines Core-Templates oder an drei Extensions, die alle dieselbe Klasse umschreiben. Jedes Drittanbieter-Modul, das Sie in ein Upgrade mitnehmen, muss geprüft, aktualisiert oder gepatcht werden.

Ein Extension-Audit vor dem Upgrade macht aus dieser Unbekannten eine Liste mit Verantwortlichen und Entscheidungen. Dieser Leitfaden beschreibt den Prozess, den wir empfehlen: Inventar, Nutzungsprüfung, Kompatibilitätsprüfung, Konfliktprüfung, danach Entfernung.

Warum die Upgrades auf 2.4.8 und 2.4.9 mehr auf dem Spiel stehen lassen

Beide aktuellen Releases haben Teile der Plattform geändert, auf die Extensions angewiesen sind:

• 2.4.8 (April 2025) brachte Kompatibilität mit PHP 8.4, entfernte PHP 8.1, stellte die Suche auf OpenSearch um und ist nicht mehr mit Elasticsearch kompatibel. Außerdem wurden mehrere Laminas-Abhängigkeiten ersetzt.
• 2.4.9 (Mai 2026) unterstützt PHP 8.5 und streicht PHP 8.2 und 8.3. Adobes Release Notes beschreiben eine native MVC-Implementierung anstelle von Laminas MVC, die Symfony-Cache-Komponente anstelle von Zend_Cache und den Wechsel des WYSIWYG-Editors von TinyMCE zu HugeRTE.

Jede Extension, die diese Bibliotheken direkt aufruft, einen eigenen Elasticsearch-Adapter mitbringt oder den Editor anpasst, braucht Aufmerksamkeit. Auch die Support-Zeiträume erhöhen den Druck: Laut Adobes Lifecycle-Policy endet der Standard-Support für 2.4.6 am 11. August 2026 und für 2.4.7 am 31. Mai 2027.

Schritt 1: Ein vollständiges Modul-Inventar erstellen

Beginnen Sie mit dem, was Magento als installiert und aktiviert erkennt:

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

Listen Sie dann auf, was Composer direkt installiert hat, mit Versionen und Beschreibungen:

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

Suchen Sie zum Schluss Code, der außerhalb von Composer liegt:

ls app/code/*/

Führen Sie alles in einer Tabelle zusammen. Filtern Sie Magento_* -Core-Module und Adobes mitgelieferte Pakete heraus und ergänzen Sie Spalten für Anbieter, installierte Version, neueste Version, Quelle (Composer oder app/code), fachlich Verantwortlichen und eine Entscheidung: behalten, aktualisieren, ersetzen oder entfernen.

Schritt 2: Ungenutzte und verwaiste Extensions finden

Ungenutzt

Deaktivierte Module sind die einfachen Kandidaten. Wenn etwas seit Monaten deaktiviert ist und niemand es vermisst, planen Sie die Entfernung. Suchen Sie bei aktivierten Modulen nach Belegen für echte Nutzung:

• Ist die Funktion im Storefront oder in einem täglichen Admin-Ablauf sichtbar? Fragen Sie die Personen, die den Shop betreiben.
• Enthalten die Datenbanktabellen aktuelle Einträge?
• Erscheint der Cronjob in cron_schedule und erledigt er sinnvolle Arbeit?
• Ist die Funktion in der Konfiguration abgeschaltet, während das Modul aktiviert bleibt?

# Von einem Anbieter angelegte Tabellen, mit Zeilenanzahl
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name LIKE 'vendorprefix_%';

# Läuft der Cron des Moduls?
SELECT job_code, status, MAX(executed_at)
FROM cron_schedule WHERE job_code LIKE 'vendorprefix_%'
GROUP BY job_code, status;

Verwaist oder nicht mehr gepflegt

composer outdated --direct
composer audit

composer outdated zeigt, für welche Pakete neuere Versionen existieren, und markiert Pakete, die als aufgegeben gekennzeichnet sind. composer audit gleicht installierte Versionen mit bekannten Sicherheitshinweisen ab. Prüfen Sie für jede Extension außerdem das Changelog des Anbieters und das Datum des letzten Releases. Ein Modul ohne Release, das Ihre Ziel-PHP-Version unterstützt, ist ein Kandidat für den Austausch.

Schritt 3: Kompatibilität mit der Zielversion prüfen

Composer-Constraints

Fragen Sie Composer, was das Upgrade blockiert, bevor Sie etwas ändern:

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

Verwenden Sie den magento/product-enterprise-edition für Adobe Commerce. Die Ausgabe listet jedes Paket, dessen Constraints mit dem Ziel kollidieren. Diese Liste ist Ihr Upgrade-Backlog.

Upgrade Compatibility Tool (Adobe Commerce)

Adobes Upgrade Compatibility Tool (UCT) analysiert die Module und den Core-Code einer Instanz gegen eine Zielversion und meldet kritische Probleme, Fehler und Warnungen. Laut Adobes Dokumentation ist es nur für Adobe-Commerce-Instanzen verfügbar und wird installiert von repo.magento.com:

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

# Eigenen Code gegen eine Zielversion prüfen
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9

# Nur neue, durch das Upgrade entstehende Probleme anzeigen
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9 \
  --ignore-current-version-compatibility-issues --min-issue-level=error

# Geänderte Core-Dateien finden
./uct/bin/uct core:code:changes /var/www/magento /path/to/vanilla

Bevor Sie sich auf den Bericht verlassen, stellen Sie sicher, dass Ihre UCT-Version das Ziel-Release unterstützt, gegen das Sie prüfen.

PHP-Versionsprüfungen (Open Source und Commerce)

Führen Sie unter Magento Open Source – oder zusätzlich zum UCT – einen statischen PHP-Kompatibilitätsscan mit PHP_CodeSniffer und dem PHPCompatibility-Standard über den Drittanbieter-Code aus:

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

Prüfen Sie, ob die installierte PHPCompatibility-Version Sniffs für Ihre Ziel-PHP-Version enthält. Statische Scans übersehen Laufzeitprobleme. Betreiben Sie den Shop deshalb zusätzlich auf Staging mit der Ziel-PHP-Version und aktiviertem Deprecation-Logging.

Typische Befunde beim Wechsel auf PHP 8.4 sind implizit nullable Parameter wie function foo(Bar $bar = null), die PHP 8.4 zugunsten von ?Bar $bar = nullals veraltet markiert. PHP 8.5 bringt weitere Deprecations, etwa die nicht-kanonischen Casts (integer) und (boolean) sowie die Verwendung von null als Array-Offset.

Schritt 4: Plugin- und Preference-Konflikte finden

Preferences ersetzen eine Core-Klasse vollständig, daher kann sich nur ein Modul durchsetzen. Around-Plugins auf stark genutzten Pfaden können sich gegenseitig stören und den Shop verlangsamen. Listen Sie sie auf:

# Von Drittanbieter-Code deklarierte Preferences
grep -rn "<preference" app/code vendor/*/*/etc --include=di.xml | grep -v "vendor/magento"

# Vollständiges DI-Bild einer Klasse, die mehrere Module berühren
bin/magento dev:di:info "Magento\Checkout\Model\ShippingInformationManagement"

dev:di:info zeigt die aktive Preference, die Konstruktor-Argumente und jedes Plugin der Klasse mit seinem Typ (before, after, around). Markieren Sie jede Core-Klasse mit Preferences von mehr als einem Anbieter und jede Klasse mit mehreren Around-Plugins. Das sind die ersten Stellen, die Sie nach dem Upgrade testen sollten.

Suchen Sie außerdem nach Template- und Layout-Overrides von Core-Dateien in Ihrem Theme. Ein geändertes Core-Template bricht den Build nicht, kann aber unbemerkt neues Markup, CSP-Nonces oder Sicherheitsfixes verschlucken.

Schritt 5: Extensions durch Core-Funktionen ersetzen

Manche Extensions wurden gekauft, um Lücken zu füllen, die Magento inzwischen geschlossen hat. Typische Beispiele, die sich zu prüfen lohnen:

Der Austausch geschieht nicht automatisch. Vergleichen Sie Funktionen, migrieren Sie Daten und schulen Sie die Nutzer neu – aber jedes Modul, das Sie streichen, ist eine Abhängigkeit weniger bei jedem künftigen Upgrade.

Schritt 6: Extensions sicher entfernen

1. Sichern Sie Datenbank und Code.
2. Zuerst auf Staging deaktivieren und einen vollständigen Regressionstest durchführen: Checkout, Zahlungen, Bestellanlage im Admin, Importe und Integrationen.
3. Prüfen Sie, welche Daten Sie behalten müssen, etwa individuelle Attribute, Bestellfelder oder Kundendaten, die das Modul gespeichert hat.
4. Entfernen Sie den Code. Für per Composer installierte Module:

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

Alternativ führt bin/magento module:uninstall Vendor_Module --backup-db für Sie composer remove aus und startet mit --remove-datadie eigene Deinstallationsroutine des Moduls. Das funktioniert nur für Module, die über Composer installiert wurden. Module in app/codedeaktivieren Sie diese, löschen das Verzeichnis und führen anschließend Folgendes aus: setup:upgrade.

5. Entfernen Sie Überreste mit Bedacht: verwaiste Tabellen, core_config_data -Einträge und EAV-Attribute. Löschen Sie Daten erst, wenn der fachlich Verantwortliche zugestimmt hat.
6. Spielen Sie die Änderung in Produktion ein – als eigenes Release vor dem Plattform-Upgrade, damit Sie Probleme auseinanderhalten können.

Häufig gestellte Fragen

Ist das Upgrade Compatibility Tool für Magento Open Source verfügbar?

Nein. Laut Adobes Dokumentation ist das Upgrade Compatibility Tool nur für Adobe-Commerce-Instanzen verfügbar. Open-Source-Projekte können Composers why-not, PHPCompatibility-Scans und ein Test-Upgrade auf Staging kombinieren.

Soll ich eine ungenutzte Extension deaktivieren oder deinstallieren?

Deinstallieren Sie sie. Ein deaktiviertes Modul bleibt in Ihrer Codebasis, kann weiterhin mit Composer-Constraints kollidieren und braucht weiterhin Updates, wenn sich seine Abhängigkeiten ändern.

Wie lange dauert ein Extension-Audit?

Das hängt davon ab, wie viele Drittanbieter-Module Sie einsetzen und wie gut sie dokumentiert sind. Das Inventar selbst ist mit den obigen Befehlen schnell erstellt. Die Zeit fließt in die Nutzungsprüfung mit dem Fachbereich und das Testen von Alternativen.

Können wir PHP und Magento gleichzeitig upgraden?

Prüfen Sie die unterstützten Kombinationen für Ihren Upgrade-Pfad. 2.4.8 erfordert für den Produktivbetrieb PHP 8.3 oder 8.4, und 2.4.9 unterstützt PHP 8.5 vollständig, wobei PHP 8.4 nur für Upgrade-Zwecke zulässig ist. Viele Teams wechseln zunächst auf die Ziel-Magento-Version mit einer PHP-Version, die beide Releases unterstützen, und stellen PHP dann in einem separaten Schritt um.

Quellen

• Release Notes zu Adobe Commerce 2.4.8
• Adobe Commerce 2.4.9 Release Notes
• Adobe Experience League: Released versions
• Adobe Experience League: Software lifecycle policy
• Adobe Experience League: Upgrade Compatibility Tool overview
• Adobe Experience League: Run the Upgrade Compatibility Tool
• Adobe Experience League: bin/magento CLI-Referenz
• Adobe Experience League: Uninstall modules
• Adobe Developer: Dependency injection configuration
• PHP-Handbuch: Veraltete Funktionen in PHP 8.4
• PHP-Handbuch: Veraltete Funktionen in PHP 8.5