Upgrade-Leitfaden für Magento 2.4.9: PHP 8.5, Symfony 7.4 und was dabei kaputtgeht

Magento Open Source und Adobe Commerce 2.4.9 ist die neueste Versionslinie und hat die längste Laufzeit: Adobe nennt regulären Support bis zum 31. Mai 2029. Für Händler auf 2.4.6 oder 2.4.7 ist sie das naheliegende Ziel.

Gleichzeitig ist es ein aufwendigeres Upgrade als ein typischer Patch. Mehrere langjährige Abhängigkeiten wurden ersetzt, die PHP-Mindestversion ist gestiegen, und einige Infrastrukturkomponenten haben sich geändert. Dieser Leitfaden erklärt, was sich geändert hat, was typischerweise kaputtgeht, und beschreibt einen Upgrade-Prozess Schritt für Schritt, den Sie an Ihren Shop anpassen können.

Was sich in 2.4.9 geändert hat

PHP 8.5, Wegfall von PHP 8.2 und 8.3

Laut den Release Notes von Adobe zu 2.4.9 wird PHP 8.5 vollständig unterstützt. PHP 8.4 ist nur für Upgrade-Zwecke zulässig und für die Produktivumgebung nicht empfohlen. PHP 8.2 und 8.3 werden nicht mehr unterstützt. Laufen Ihre Server heute mit 8.2 oder 8.3, ist das PHP-Upgrade Teil dieses Projekts und kein separates Vorhaben.

Symfony 7.4 LTS

Alle Symfony-Abhängigkeiten wechseln auf Symfony 7.4 LTS. Symfony 7 hat strengere Typdeklarationen eingeführt und Methodensignaturen geändert. Jede individuelle Klasse, die eine Symfony-Komponente erweitert, muss geprüft werden. Der häufigste Fall sind CLI-Befehle: Individuelle bin/magento -Befehle erweitern Symfony\Component\Console\Command\Command, und ihre configure() und execute() -Signaturen müssen zur neuen Elternklasse passen.

// Symfony 7 expects an int return type on execute()
protected function execute(InputInterface $input, OutputInterface $output): int
{
    // ...
    return Command::SUCCESS;
}

Laminas MVC durch native MVC-Implementierung ersetzt

Adobe hat die alte Laminas-MVC-Schicht durch eine eigene MVC-Implementierung von Magento ersetzt. Der meiste Shop-Code greift nie direkt auf Laminas MVC zu, aber einige ältere Extensions und individuelle Module importieren Laminas-Klassen für Request-Handling, Routing oder HTTP-Responses. Durchsuchen Sie Ihre Codebasis nach diesen Imports, bevor Sie beginnen.

Zend_Cache durch Symfony Cache ersetzt

Die veraltete Komponente Zend_Cache weicht Symfony Cache. Laut Adobe werden bestehende Cache-Backends weiterhin unterstützt, und Änderungen an Integrationen sind nicht erforderlich. Individuelle Cache-Backends oder Code, der Zend_Cache-Klassen direkt aufruft, müssen dennoch getestet werden.

Weitere Änderungen, die Upgrades betreffen

• WYSIWYG-Editor: TinyMCE wird durch HugeRTE ersetzt, da der Support für TinyMCE 5 und 6 ausgelaufen ist. Extensions, die den Editor anpassen, müssen geprüft werden.
• OAuth: Die OAuth-Bibliothek eines Drittanbieters wird durch native PHP-Funktionen ersetzt.
• JWT-Framework: auf die neueste Major-Version aktualisiert.
• Zwei-Faktor-Authentifizierung: Admins müssen jetzt nur noch einen Anbieter einrichten statt aller aktivierten Anbieter.
• JavaScript-Bibliotheken: jQuery UI, jQuery Validate, Less.js, Underscore.js, Chart.js und weitere wurden aktualisiert, was sich auf individuelle Themes auswirken kann.

CAPTCHA bei der Kontoerstellung per API erzwungen

Ist CAPTCHA oder reCAPTCHA für das Formular „Konto erstellen“ im Storefront aktiviert, erzwingt 2.4.9 nun dieselbe Validierung auch bei der Erstellung von Kundenkonten über REST und GraphQL. Außerdem wurde die reCAPTCHA-Validierung zu mehreren GraphQL-Mutations hinzugefügt, darunter updateCustomer.

Damit wird ein häufiger Weg für Bot-Registrierungen geschlossen. Gleichzeitig funktionieren Headless-Frontends, mobile Apps und Integrationen nicht mehr, die Kundenkonten über die API anlegen, ohne ein CAPTCHA-Token zu senden. Testen Sie diese Abläufe gezielt.

Systemanforderungen

Die folgende Tabelle gibt die Release Notes zu 2.4.9 und die Seite mit den Systemanforderungen von Adobe zum Zeitpunkt der Erstellung wieder. Prüfen Sie vor Änderungen an der Infrastruktur immer die aktuelle Seite mit den Systemanforderungen, da Adobe sie mit jedem Patch aktualisiert.

Zwei Punkte fallen auf. Adobe weist darauf hin, dass der Support für MySQL 8.0 am 30. April 2026 ausgelaufen ist. Und die On-Premises-Tabelle für 2.4.9 nennt Valkey statt Redis für Caching und Sessions. Planen Sie diesen Wechsel ein, wenn Sie noch Redis betreiben.

Upgrade-Prozess Schritt für Schritt

1. Code und Extensions prüfen

Beginnen Sie mit einer Bestandsaufnahme, denn hier steckt der größte Aufwand.

# list installed third-party modules
bin/magento module:status --enabled | grep -v "^Magento_"

# find code that touches replaced components
grep -rn "Laminas\\\\Mvc\|Zend_Cache\|Symfony\\\\Component\\\\Console" app/code vendor/<your-vendors>

Prüfen Sie bei jeder Extension, ob der Anbieter eine Version veröffentlicht hat, die als kompatibel mit 2.4.9 und PHP 8.5 gekennzeichnet ist. Entfernen Sie Module, die Sie nicht mehr nutzen. Jedes entfernte Modul ist eines weniger, das getestet werden muss.

2. Eine Staging-Umgebung vorbereiten, die den neuen Stack abbildet

Bauen Sie Staging auf PHP 8.5, OpenSearch 3, MySQL 8.4 oder MariaDB 11.8/12.x und Valkey auf. Spielen Sie eine aktuelle Kopie der Produktivdaten ein. Wenn Sie Code und Infrastruktur gemeinsam auf Staging aktualisieren, zeigen sich echte Probleme frühzeitig.

3. Backup erstellen und Wartungsmodus aktivieren

bin/magento maintenance:enable
mysqldump --single-transaction --routines --triggers dbname > pre-249.sql
tar -czf pre-249-code.tgz app composer.json composer.lock

4. Composer-Anforderungen aktualisieren

Für Magento Open Source:

composer require-commerce magento/product-community-edition 2.4.9 --no-update
composer update

Für Adobe Commerce verwenden Sie stattdessen magento/product-enterprise-edition. Der require-commerce -Befehl stammt aus dem composer-root-update-Plugin von Adobe und passt die Root-Abhängigkeiten für Sie an. Rechnen Sie beim ersten Durchlauf mit Konflikten. Lösen Sie diese durch neuere Extension-Versionen, nicht durch das Erzwingen älterer Constraints.

5. Upgrade ausführen und neu aufbauen

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento indexer:reindex
bin/magento cache:flush
bin/magento maintenance:disable

Beheben Sie zuerst die Kompilierungsfehler. Abweichende Signaturen gegenüber Symfony 7.4 und fehlende Laminas-Klassen zeigen sich meist an dieser Stelle.

Häufige Fehler nach dem Composer-Schritt

• Declaration must be compatible with Symfony\Component\…: Eine individuelle Klasse überschreibt eine Symfony-Methode mit einer alten Signatur. Ergänzen Sie die Parameter- und Rückgabetypen, die die Elternklasse jetzt deklariert.
• Class “Laminas\Mvc\…” not found: Ein Modul hängt noch von Laminas MVC ab. Aktualisieren Sie die Extension oder refaktorieren Sie den Code, sodass er die eigenen Request- und Response-Klassen von Magento nutzt.
• Composer-Konflikte bei der PHP-Version: Die composer.json einer Extension begrenzt PHP auf eine Version unter 8.5. Prüfen Sie, ob der Anbieter ein neueres Release hat, bevor Sie einen Fork in Betracht ziehen.
• Editor-Felder im Admin bleiben leer: Ein Modul passt die TinyMCE-Konfiguration an, die unter HugeRTE nicht mehr greift.

Dokumentieren Sie jeden Fix in Ihrem Repository mit einer aussagekräftigen Commit-Nachricht. Beim Produktivlauf soll dieselbe Abfolge sauber und ohne manuelle Eingriffe durchlaufen.

6. Testen, was am ehesten kaputtgeht

• Den Checkout von Anfang bis Ende mit jeder Zahlungsart und jedem Versanddienstleister.
• Die Kundenregistrierung im Storefront, in der mobilen App und in jedem Headless-Frontend.
• Individuelle CLI-Befehle und Cronjobs.
• Die CMS-Bearbeitung im Admin, jetzt mit HugeRTE.
• ERP-, PIM- und Marktplatz-Integrationen, auch solche mit OAuth.
• Suchergebnisse und Layered Navigation auf OpenSearch 3.

7. Die neuesten Sicherheitspatches einspielen

Eine frische 2.4.9-Installation ist nicht automatisch auf dem neuesten Stand. Im September 2026 veröffentlichte Adobe das Update APSB26-138 und separat den Hotfix APSB26-146 für die aktiv ausgenutzte Lücke CVE-2026-75650 (StyleSmuggler). Der Hotfix ist nicht im isolierten September-Patch enthalten. Spielen Sie also beide ein, bevor Sie live gehen.

8. Die Umstellung der Produktivumgebung planen

Proben Sie das Deployment auf Staging mit Zeitmessung, legen Sie einen Rollback-Punkt fest und planen Sie das Release in einem Zeitfenster mit wenig Traffic. Beobachten Sie in den ersten Tagen Fehlerlogs, Conversion-Rate und fehlgeschlagene Zahlungen genau.

Häufig gestellte Fragen

Wie lange wird Magento 2.4.9 unterstützt?

Laut der Adobe-Seite mit den veröffentlichten Versionen wird 2.4.9 regulär bis zum 31. Mai 2029 unterstützt. Veröffentlicht wurde es am 12. Mai 2026.

Kann ich 2.4.9 mit PHP 8.3 betreiben?

Nein. Laut den Release Notes von Adobe werden PHP 8.2 und 8.3 nicht mehr unterstützt. PHP 8.5 wird vollständig unterstützt, 8.4 ist nur für Upgrade-Zwecke zulässig.

Funktionieren meine Extensions unter 2.4.9?

Das zeigen nur Tests. Am stärksten gefährdet sind Extensions, die Symfony-Klassen erweitern, Laminas MVC direkt nutzen, den WYSIWYG-Editor anpassen oder Kunden über die API anlegen.

Sollte ich stattdessen auf 2.4.8 wechseln, weil das weniger Aufwand bedeutet?

2.4.8 wird bis zum 31. Mai 2028 unterstützt, ein Jahr kürzer als 2.4.9. Wenn Sie ohnehin ein großes Upgrade durchführen, ersparen Sie sich mit 2.4.9 meist eine weitere Framework-Migration kurz danach.

Quellen

• Adobe Commerce 2.4.9 Release Notes
• Magento Open Source 2.4.9 Release Notes
• Adobe Commerce: veröffentlichte Versionen und Support-Zeiträume
• Adobe Commerce: Systemanforderungen
• Security update available for Adobe Commerce, APSB26-138
• Critical security update for Adobe Commerce, APSB26-146