Drei Entwicklungen, die Ihre Projektplanung verändern

Wenn sich innerhalb von zwei Wochen Doctrine, Symfony und Shopware gleichzeitig bewegen, lohnt sich ein genauer Blick. Nicht wegen der Versionsnummern, sondern wegen der konkreten Konsequenzen für laufende Projekte. Doctrine ORM 4.0 hat die aktive Entwicklung aufgenommen. Symfony 8.1 spaltet das monolithische FrameworkBundle auf. Und Shopware liefert mit Version 6.7.9.0 eine native Lösung für den gesetzlich vorgeschriebenen Widerrufsbutton, während die nächste Major-Version auf 2027 verschoben wurde.

Was alle drei Themen verbindet: Sie erzeugen Handlungsdruck. Wer Projekte auf Doctrine 2.x betreibt, hat jetzt ein Zeitfenster, das sich schließt. Wer Symfony-Bundles entwickelt, muss verstehen, wie sich die Bundle-Architektur fundamental verändert. Und wer einen Shopware-Shop betreibt, hat mit dem 19. Juni 2026 eine harte gesetzliche Deadline.

Die entscheidende Frage für Ihr Projekt: Welche dieser Entwicklungen betrifft Sie am meisten, und was sollten Sie als Erstes angehen?

Doctrine ORM 4.0: Das Ende der 2.x-Ära rückt näher

Was passiert gerade?

Die Doctrine-Maintainer haben im Oktober 2025 beim Core Team Meetup in Paris eine wichtige Entscheidung getroffen: Das End-of-Life für ORM 2.x wurde von Februar 2026 auf mindestens Februar 2027 verschoben. Das klingt zunächst nach Entwarnung, ist aber das Gegenteil. Denn seit März 2026 gilt die sogenannte Restricted Maintenance Policy: In den 2.x-Branch fließen nur noch PHP-Versionskompatibilität (für PHP 8.5, 8.6 oder 9.0), Security-Fixes und Verbesserungen der Forward-Kompatibilität mit ORM 3.

Parallel dazu hat die aktive Entwicklung von ORM 4.0 begonnen. Der 4.0-Milestone auf GitHub zeigt 80% Fortschritt (33 von 41 Issues geschlossen, Stand Februar 2026). ORM 4.0 wird PHP 8.4 als Minimum erfordern und komplett auf Native Lazy Objects setzen. Ein Hackathon ist für Herbst 2026 geplant, ein Release möglicherweise Ende 2026 oder Anfang 2027.

Warum die Adoption von ORM 3 stockt

Ein häufiger Fehler, den ich in Audits sehe: Teams unterschätzen den Migrationsaufwand von ORM 2.x auf 3.x. Die Zahlen bestätigen das. Laut Packagist liegt die ORM-3-Adoption bei etwa 25-30% der ORM-2-Installationen. DBAL 4 ist mit rund 60% deutlich weiter. Das zeigt, dass die Datenbank-Abstraktionsschicht leichter zu migrieren ist als der ORM-Kern.

Die Doctrine-Maintainer haben reagiert und einige Deprecations seit dem initialen 3.0-Release zurückgenommen (insbesondere Partial Objects). Auch die Upgrade Guides wurden verbessert. Trotzdem bleibt das Kernproblem: Projekte auf ORM 2.x stehen vor einer dreistufigen Migration (2.x → 3.x → 4.x). Wer den 2.x→3.x-Wechsel aufschiebt, handelt sich den doppelten Aufwand ein.

Was Native Lazy Objects für die Proxy-Architektur bedeuten

ORM 4.0 setzt vollständig auf PHP 8.4 Native Lazy Objects. Das klingt nach einem internen Implementierungsdetail, hat aber weitreichende Konsequenzen. Bisher generiert Doctrine Proxy-Klassen, die Ihre Entity-Klassen erweitern. Diese Proxies überschreiben Getter-Methoden, um Lazy Loading zu implementieren. Mit Native Lazy Objects entfällt das komplett.

// Doctrine ORM 2.x/3.x: Generierte Proxy-Klasse
class UserProxy extends User {
    public function getName(): string {
        $this->__initializer__ && $this->__initializer__->__invoke($this, 'getName', []);
        return parent::getName();
    }
}

// Doctrine ORM 4.0: PHP 8.4 Native Lazy Object
$user = $reflector->newLazyProxy(
    User::class,
    function () use ($entityManager, $id) {
        return $entityManager->find(User::class, $id);
    }
);

Die Auswirkungen auf bestehenden Code:

Alles, was instanceof-Checks gegen Proxy-Klassen macht, funktioniert nicht mehr. Custom Serializer, die Proxy-Properties filtern, brauchen ein Refactoring. Tools, die auf generierte Proxy-Dateien im Dateisystem angewiesen sind (Cache-Warming, Deployment-Scripts), müssen angepasst werden.

Aus meiner Erfahrung mit Symfony-Projekten: Besonders betroffen sind Projekte mit Custom Hydrators, eigenen Entity-Listenern, die auf Proxy-Internals zugreifen, und Serialisierungslogik, die zwischen "echten" Entities und Proxies unterscheidet. Ein typisches Pattern, das brechen wird:

// Dieses Pattern funktioniert mit ORM 4.0 nicht mehr:
if ($entity instanceof \Doctrine\ORM\Proxy\Proxy) {
    // Spezialbehandlung für nicht-initialisierte Entities
    $entity->__load();
}

// Stattdessen: PHP 8.4 Reflection API
$reflector = new \ReflectionClass($entity);
if ($reflector->isUninitializedLazyObject($entity)) {
    $reflector->initializeLazyObject($entity);
}

Die Tragweite wird klarer, wenn man sich die typische Agentur-Situation vorstellt: Ein Shopware-Plugin, das vor zwei Jahren geschrieben wurde, nutzt Proxy-Checks für Performance-Optimierung. Das Plugin funktioniert seit Jahren stabil. Aber beim nächsten Doctrine-Upgrade bricht es stillschweigend, weil die Proxy-Klasse einfach nicht mehr existiert. Kein Fehler, kein Warning, nur falsches Verhalten. Diese Art von Bugs ist schwer zu finden und teuer zu debuggen.

Wie ich im Artikel zu PHP 8.6 beschrieben habe, verändern die neuen PHP-Features die gesamte Architektur von Frameworks und Libraries. Native Lazy Objects in Doctrine ORM 4.0 sind ein konkretes Beispiel dafür. ORM 3.4.0 unterstützt Native Lazy Objects bereits optional auf PHP 8.4+. Wer jetzt auf ORM 3.x migriert und PHP 8.4 einsetzt, kann die neue Proxy-Architektur bereits testen und sich auf ORM 4.0 vorbereiten.

Symfony 8.1: FrameworkBundle wird modular

Was bedeutet die Aufspaltung konkret?

Symfony 8.1 macht einen Architekturschritt, der langfristig jedes Symfony-Projekt betrifft: Das monolithische FrameworkBundle wird in kleinere, eigenständige Bundles aufgeteilt. Als erste Schritte wurden ServicesBundle und ConsoleBundle eingeführt.

Das FrameworkBundle war seit Symfony 2.0 das "Gott-Bundle", das praktisch alles zusammenhielt: Service-Container-Konfiguration, Console-Commands, Routing, Session-Management, Caching, Form-Handling, Validation. Die neue Architektur extrahiert diese Verantwortlichkeiten in dedizierte Bundles.

# Symfony <= 8.0: Alles im FrameworkBundle
// config/bundles.php
return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
];

# Symfony 8.1+: Granulare Bundle-Auswahl möglich
// config/bundles.php
return [
    Symfony\Bundle\ServicesBundle\ServicesBundle::class => ['all' => true],
    Symfony\Bundle\ConsoleBundle\ConsoleBundle::class => ['all' => true],
    // ... nur was Sie wirklich brauchen
];

Was die Dokumentation nicht erwähnt: Diese Aufspaltung ist der Beginn, nicht das Ende. ServicesBundle und ConsoleBundle sind die "einfachsten" Extraktionen. Die komplexeren Teile (Routing, Security, Form) folgen in späteren 8.x-Versionen. Die Reihenfolge ist bewusst gewählt, denn die DependencyInjection- und Console-Komponenten haben die wenigsten gegenseitigen Abhängigkeiten.

Welche Auswirkungen hat das auf bestehende Projekte?

Kurzfristig: Keine Breaking Changes. FrameworkBundle existiert weiterhin und registriert ServicesBundle und ConsoleBundle automatisch. Symfony Flex übernimmt die Bundle-Registrierung transparent. Bestehende framework.yaml-Konfigurationen funktionieren unverändert.

Mittelfristig: Bundle-Konfigurationen werden sich ändern. Was heute unter framework: konfiguriert wird, wandert in eigene Konfigurationsschlüssel. Service-Registrierungen, die über FrameworkBundle-Compiler-Passes laufen, müssen auf die neuen Bundle-Zuständigkeiten angepasst werden.

In der Praxis scheitert das oft an Custom Compiler Passes. Agenturen, die eigene Bundle-Konfigurationen schreiben, die sich auf FrameworkBundle-Internals verlassen (Extension-Klassen, bestimmte Container-Parameter), müssen diese Abhängigkeiten identifizieren und auflösen. Das ist kein triviales Refactoring.

Ein konkretes Beispiel: Wenn Ihr Custom Bundle einen Compiler Pass registriert, der den framework.router-Parameter ausliest oder FrameworkBundle-spezifische Service-Definitionen modifiziert, wird dieser Pass möglicherweise nicht mehr funktionieren, wenn das Routing in ein eigenständiges Bundle wandert. Die Lösung ist, Compiler Passes so zu schreiben, dass sie Service-Definitionen über Interfaces und Tags referenzieren, nicht über Bundle-spezifische Bezeichner.

// Anti-Pattern: Direkte Abhängigkeit auf FrameworkBundle-Internals
class MyCompilerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container): void
    {
        // FRAGIL: Referenziert FrameworkBundle-spezifischen Service
        $definition = $container->getDefinition('framework.router');
        $definition->addMethodCall('addLoader', [/* ... */]);
    }
}

// Besser: Tag-basierte Referenz (Bundle-unabhängig)
class MyCompilerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container): void
    {
        $taggedServices = $container->findTaggedServiceIds('routing.loader');
        // Arbeitet mit dem Tag-System statt direkten Service-IDs
    }
}

Was bringt die Modularisierung?

Der technische Vorteil ist klar: Leichtgewichtigere Symfony-Installationen. Microservices oder CLI-Tools, die kein HTTP-Stack brauchen, können auf das ConsoleBundle beschränkt werden, ohne das gesamte FrameworkBundle zu laden. Für Enterprise-CMS-Projekte bedeutet das: geringerer Memory-Footprint, schnellere Boot-Zeiten, klarere Dependency Trees.

Für Agenturen, die Symfony-basierte Produkte (Shopware, Sulu, Ibexa) einsetzen, hat die Modularisierung eine strategische Dimension: Diese Produkte können in Zukunft gezielter Symfony-Komponenten nutzen, ohne den Ballast des gesamten FrameworkBundle mitzuschleppen.

Lohnt sich die Vorbereitung jetzt schon?

Aus meiner Projekterfahrung: Ja, aber nicht durch proaktives Refactoring. Der richtige Zeitpunkt ist die nächste ohnehin geplante Symfony-Version-Aktualisierung. Was Sie jetzt tun können: Identifizieren Sie Custom Compiler Passes, die FrameworkBundle-Internals referenzieren. Dokumentieren Sie, welche framework:-Konfigurationsschlüssel Sie tatsächlich nutzen. Und vermeiden Sie es, neue Abhängigkeiten auf FrameworkBundle-spezifische Extension-Klassen aufzubauen.

Parallel dazu unterstützt Symfony Polyfill 1.34.0 jetzt Features von PHP 8.4, 8.5 und 8.6. Und Twig 3.24.0 bringt verbessertes HTML-Attribute-Handling. Beides sind kleinere Updates, die aber in der täglichen Arbeit spürbar sind.

Shopware 6.7.9.0: Widerrufsbutton als Core-Feature und 6.8 auf 2027 verschoben

Warum der Widerrufsbutton geschäftskritisch ist

Am 19. Juni 2026 wird der elektronische Widerrufsbutton gemäß § 356a BGB (Umsetzung der EU-Richtlinie 2023/2673) für alle B2C-Onlineshops verpflichtend. Wer nicht compliant ist, riskiert Bußgelder bis 50.000 € oder 4% des Jahresumsatzes. Die Widerrufsfrist verlängert sich bei fehlender Umsetzung auf 12 Monate plus 14 Tage statt der üblichen 14 Tage. Hinzu kommt das Abmahnrisiko.

Shopware hat mit dem Minor Release 6.7.9.0 (erwartet April 2026) eine native, kostenfreie Lösung angekündigt. Die Funktion wird als Bestandteil des Core-Systems in der Community Edition und höheren Plänen bereitgestellt. Zusätzlich ist ein Backport auf Shopware 6.6 geplant, sodass auch Händler ohne Versionssprung die gesetzlichen Anforderungen erfüllen können.

Wie ist die technische Implementierung aufgebaut?

Die native Shopware-Lösung umfasst ein zweistufiges Widerrufsverfahren: Im ersten Schritt füllt der Kunde ein Formular aus (Name, E-Mail, Bestellnummer, optionaler Kommentar). Im zweiten Schritt bestätigt der Kunde den Widerruf auf einer Vorschau-Seite. Darauf folgt eine automatische Eingangsbestätigung per E-Mail.

Aus Symfony-Entwickler-Perspektive ist die Architektur interessant: Das Widerrufsformular wird als CMS-Element über Shopping Experiences integriert. Das bedeutet flexible Platzierung im Shop-Layout, ohne Template-Anpassungen. Die Verarbeitung läuft über Shopwares Event-System, wobei der Flow Builder für automatische Bestätigungs- und Benachrichtigungsmails genutzt wird.

# Shopware 6.7.9.0: Widerrufsbutton-Platzierungsoptionen
# 1. Kundenkonto-Sidebar (automatisch bei berechtigten Bestellungen)
# 2. Footer (für alle Besucher, auch ohne Login)
# 3. Bestellliste & Bestelldetail (pro Bestellung)
# 4. CMS Shopping Experiences (Drag-and-Drop)

# Die Widerrufsfrist wird systemseitig geprüft:
# - Button erscheint nur innerhalb der Widerrufsfrist
# - Automatisches Ausblenden nach Fristablauf
# - Bereits widerrufene Bestellungen werden erkannt

Was viele unterschätzen: Die technische Schaltfläche ist nur die halbe Miete. Die organisatorische Integration ist mindestens genauso wichtig. Wer prüft eingehende Widerrufe? Wie werden Fristen und Ausschlussgründe dokumentiert? Wie läuft die Verarbeitung der automatischen Eingangsbestätigung? Diese Prozesse müssen vor dem Go-Live definiert und getestet werden.

Was bedeutet die Verschiebung von Shopware 6.8 auf 2027?

Shopware hat Ende 2025 offiziell bestätigt: Die nächste Major-Version 6.8 kommt erst 2027, nicht wie ursprünglich geplant 2026. Der Extended Support für Shopware 6.6 wird bis zum 6.8-Release verlängert. Shopwares Fokus liegt auf Stabilität, Performance, Sicherheit und neuen Agentic-AI-Features.

Für Agenturen und Shop-Betreiber verändert das die Upgrade-Strategie fundamental. Wer auf Shopware 6.6 läuft, hat jetzt mehr Zeit für den Wechsel auf 6.7. Wer auf 6.7 ist, kann sich auf Minor-Updates konzentrieren, ohne einen Major-Versionssprung planen zu müssen. Wie ich im Artikel zu Shopware 6.7.7.0 und Symfony 7.4 LTS beschrieben habe, bringen bereits die Minor-Releases erhebliche Änderungen mit sich.

Die strategische Empfehlung für Shopware-Projekte: Nutzen Sie das verlängerte Zeitfenster, aber schieben Sie den 6.7-Upgrade nicht auf. Die Widerrufsbutton-Pflicht zum 19. Juni 2026 ist ein natürlicher Anlass, ohnehin fällige Updates zusammenzufassen.

Welche Plugins sind betroffen?

Ein häufiger Fehler, den ich in Audits sehe: Teams aktualisieren Shopware, testen aber nicht die Plugin-Kompatibilität mit dem neuen Widerrufsformular. Plugins, die das Checkout-Template anpassen, den Footer modifizieren oder eigene Kundenkonto-Seiten implementieren, können den Widerrufsbutton verdecken oder seine Funktionalität beeinträchtigen.

Bei individuellen Templates oder Headless-Architekturen muss der Widerrufsbutton im jeweiligen Frontend aktiv eingebunden und getestet werden. Die native Lösung funktioniert out-of-the-box nur mit der Standard-Storefront. Für Custom-Frontends bedeutet das: Routing, Form-Handling und die automatische Bestätigungsmail müssen eigenständig implementiert werden.

Aus Symfony-Entwickler-Sicht ist der Backport auf Shopware 6.6 technisch bemerkenswert. Shopware portiert hier ein Feature aus der 6.7-Architektur (mit Vue 3, Vite, Symfony 7.4) zurück auf die ältere 6.6-Basis. Das ist keine triviale Aufgabe und zeigt, wie ernst Shopware die gesetzliche Deadline nimmt. Für Agenturen bedeutet es: Auch Shops, die aus guten Gründen noch auf 6.6 laufen (Plugin-Kompatibilität, ERP-Integration), können compliant werden, ohne einen Major-Upgrade erzwingen zu müssen.

Ein Punkt, der in der Diskussion oft untergeht: Die DSGVO-Implikationen. Die Verarbeitung der Daten im Rahmen des Widerrufsprozesses ist eine zusätzliche Datenverarbeitung, die mit Zweck und Rechtsgrundlage in Ihrer Datenschutzerklärung dokumentiert werden muss. Bestellbestätigung, Versandbestätigung und die neue Widerrufsbestätigung sollten geprüft und gegebenenfalls ergänzt werden.

Strategische Handlungsempfehlungen

Welcher Migrationspfad ist der richtige?

Für Doctrine-ORM-2.x-Projekte: Starten Sie jetzt mit der Migration auf ORM 3.x. Nicht übermorgen, nicht "wenn Zeit ist". Das Zeitfenster zwischen Restricted Maintenance (seit März 2026) und dem endgültigen EOL (mindestens Februar 2027) ist Ihre Planungsgrundlage. Aktualisieren Sie zuerst auf die neueste 2.x-Version und beheben Sie alle Deprecation Warnings. Dann migrieren Sie auf DBAL 4 (der einfachere Schritt) und anschließend auf ORM 3.x. Doctrine hat die Migration-Blocker-Diskussion auf GitHub geöffnet. Wenn Sie spezifische Probleme haben: Melden Sie sich dort.

Für Symfony-Projekte: Keine Panik wegen der FrameworkBundle-Aufspaltung. Das ist ein langfristiger Prozess, kein akuter Handlungsbedarf. Priorisieren Sie stattdessen das Upgrade auf Symfony 7.4 LTS, wenn Sie noch auf 6.4 LTS stehen. Das gibt Ihnen Support bis 2029 und eine saubere Basis für die spätere Transition zu den modularen Bundles.

Für Shopware-Projekte: Die Priorität ist klar: Widerrufsbutton-Compliance bis 19. Juni 2026. Planen Sie das Update auf 6.7.9.0 ein, sobald die Version verfügbar ist. Testen Sie Plugin-Kompatibilität. Definieren Sie interne Prozesse für die Widerrufsbearbeitung. Und klären Sie mit Ihrem Rechtsbeistand (Händlerbund, Trusted Shops, IT-Recht-Kanzlei), ob Ihre Datenschutzerklärung die zusätzliche Datenverarbeitung im Rahmen des Widerrufsprozesses abbildet.

Priorisierung nach Dringlichkeit

Die Reihenfolge ist für die meisten Projekte klar: Shopware Widerrufsbutton zuerst (harte gesetzliche Deadline), dann Doctrine ORM Migration (EOL-Zeitfenster schließt sich), dann Symfony FrameworkBundle-Vorbereitung (langfristig, kein akuter Handlungsdruck). Als Symfony-Entwickler mit Fokus auf KMU-Projekte sehe ich diese Priorisierung regelmäßig in der Praxis bestätigt.

Zusammenfassung und Ausblick

KW16 bringt drei Entwicklungen, die unterschiedliche Zeithorizonte bedienen:

Sofortiger Handlungsbedarf: Shopware Widerrufsbutton. Deadline 19. Juni 2026, native Lösung mit 6.7.9.0 verfügbar. Nicht aufschieben.

Mittelfristiger Handlungsbedarf (6-12 Monate): Doctrine ORM 2.x → 3.x Migration. Restricted Maintenance seit März 2026, EOL mindestens Februar 2027. Die dreistufige Migration (2.x → 3.x → 4.x) wird nicht einfacher, je länger man wartet.

Langfristige Vorbereitung: Symfony FrameworkBundle-Modularisierung. Kein akuter Handlungsdruck, aber der Architekturtrend ist klar. Vermeiden Sie neue Abhängigkeiten auf FrameworkBundle-Internals.

Im Herbst 2026 dürften wir mehr Details zu Doctrine ORM 4.0 sehen (der Hackathon ist geplant). Symfony 8.2 und 8.3 werden weitere Bundles aus dem FrameworkBundle extrahieren. Und für Shopware wird die Frage spannend, welche Features die Minor-Releases bis zum 6.8-Major in 2027 bringen.

Evaluierung für Ihr Projekt

Doctrine-Migration, Symfony-Upgrade oder Shopware-Compliance: Jede dieser Entwicklungen erfordert eine individuelle Analyse Ihrer Projektarchitektur. Welche Doctrine-Versionen laufen in Ihren Projekten? Wie abhängig sind Ihre Bundles von FrameworkBundle-Internals? Ist Ihr Shopware-Shop bereit für den Widerrufsbutton?

In einem kostenlosen Erstgespräch analysiere ich Ihren konkreten Handlungsbedarf und gebe eine realistische Aufwandseinschätzung. Ohne Vertriebsgespräch, ohne Upselling, direkt auf den Punkt.

→ Kostenloses Erstgespräch vereinbaren

Dennis Schwenker-Sanders ist PHP & Symfony-Entwickler mit Fokus auf Migrationen, Architektur-Entscheidungen und E-Commerce-Projekte für deutsche KMU und Agenturen. Seit über 15 Jahren begleitet er Unternehmen bei der technischen Weiterentwicklung ihrer PHP-Anwendungen.