Ein Shopware-Plugin. Entwickelt für den Lebenszyklus einer URL.

Product 404 Redirects ist meine eigene veröffentlichte Erweiterung. Diese Fallstudie erklärt den Resolver und die Kompatibilitätsänderungen in 1.1.0 für Shopware 6.7 und 0.1.2 für Shopware 6.6 anhand dokumentierter Resolver- und Integrationstests.

Das Problem beginnt, bevor das Produkt verschwindet

Ein gelöschtes Produkt kann weiterhin über E-Mails, Lesezeichen und Suchergebnisse verlinkt sein. Beim späteren Aufruf sind das Produkt und seine Kategoriezuordnung möglicherweise bereits entfernt. Die Implementierung hat deshalb zwei zusammenhängende Aufgaben: brauchbare Daten rund um das Löschen erfassen und sie bei späteren Aufrufen verwenden.

Ich habe die Erweiterung um Shopwares Produktlebenszyklus und Storefront-Routing aufgebaut. Das Ergebnis ist ein veröffentlichtes, konfigurierbares Plugin mit Administrationsoberfläche und Verarbeitung innerhalb des Shops.

  1. Produkt löschen

    Verfügbare URL- und Kategoriedaten erfassen; nach Erfolg speichern.

  2. Shopwares SEO-Resolver

    Aufgelöste Routen bewahren; geeignete alte Pfade zuordnen.

  3. Kontrolle des Händlers

    Ziele, Regeln, Hinweise und Aktivität prüfen.

Zuerst erfassen, nach erfolgreichem Löschen speichern

Der Subscriber für Löschvorgänge liest Produkt-SEO-Pfade, übersetzte Namen und eine mögliche Kategorie, solange die Informationen verfügbar sind. Er registriert einen Success-Callback, der die Weiterleitungsregeln nach erfolgreichem Löschen speichert.

Der aktuelle Code überspringt Headless-Verkaufskanäle und Einträge ohne Kategorie-URL. Die Regelkennung wird aus Quellpfad und Verkaufskanal abgeleitet, sodass wiederholte Erfassung dieselbe Regel aktualisieren kann. So bleibt die Verbindung zu den tatsächlichen Shop-URLs nachvollziehbar.

Shopware löst die Adresse zuerst auf

Die Erweiterung dekoriert Shopwares SEO-Resolver. Zuerst wird die Plattform um Auflösung der Adresse gebeten. Ein vorhandenes kanonisches Ziel, eine kanonische Route oder ein bereits von Shopware aufgelöster Pfad bleibt erhalten.

Nur ein nicht aufgelöster, nicht leerer Pfad erreicht bei aktiviertem Plugin die Weiterleitungssuche. Eine passende Regel liefert ein kanonisches Ziel für Shopwares Routing. Ein Ziel, das nach Normalisierung der Schrägstriche der Quelle entspricht, wird ignoriert, um eine direkte Weiterleitung auf sich selbst zu vermeiden.

Die Suche prüft gespeicherte Regeln und verfügbare SEO-Historie. Verkaufskanal und Sprache werden übergeben; der Resolver fordert keinen globalen Fallback für einen beliebigen unbekannten Pfad an. Historische Zuordnungen hängen weiterhin von den erhaltenen Daten ab.

Überblick und Kontrolle für den Händler

Das Administrationsmodul zeigt Regeln, Ziele, Aktivierungsschalter und Aufrufzahlen. Das Ziel bleibt eine inhaltliche Entscheidung: Händler können einen ungeeigneten Standard durch eine relevantere Seite ersetzen.

Ein Response-Subscriber protokolliert eine passende Weiterleitung und kann ein kurzlebiges Cookie für den optionalen Storefront-Hinweis setzen. In dieser Version enthalten die Log-Einträge Regel, Quelle, Ziel und Zeitpunkte, ohne IP-Hashes oder User Agents der Besucher. Die Standardfrist für die Bereinigung beträgt 30 Tage.

Kompatibilitätsprüfungen der aktuellen Versionen

Am 16. September 2026 wurde Version 1.1.0 auf einem installierten Shopware 6.7.14.1 und Version 0.1.2 auf einem installierten Shopware 6.6.10.25 geprüft.

Geprüft wurden eine bestehende Produktweiterleitung, die Zielseite, ein lesbares Secure-Cookie für den Hinweis sowie die native Cookie-Konfiguration mit aktiviertem und deaktiviertem Standard-Banner. Gespeicherte Weiterleitungen und Kategorieverweise blieben bei der Schemaaktualisierung erhalten. Ein Chromium-Test bestätigte außerdem den sichtbaren Hinweis im 6.6-Shop.

Beide Updates korrigieren einen unvollständigen Kategorie-Fremdschlüssel und verwenden YAML-Konfiguration. Die 6.7-Ausgabe nutzt das Cookie-Sammelereignis und die automatische Erkennung von Administration-Texten. Die 6.6-Ausgabe behält ihren kompatiblen Cookie-Provider und ihre Textregistrierung mit zusätzlichen Prüfungen angepasster Cookie-Gruppen.

Die verwendeten APIs wurden gegen die Mindestanforderungen geprüft; nicht jede ältere Shopware-Patchversion wurde installiert und getestet. Die Funktionstests auf PHP 8.5 bestanden, aber die Composer-Sperrdatei des 6.6-Testshops für PHP 8.2 benötigt andere Abhängigkeitsversionen für einen vollständigen Betrieb auf PHP 8.5. Der Bericht unterscheidet diese Prüfungen von den folgenden historischen isolierten Tests.

Neun isolierte Prüfungen des Resolvers

Am 8. September 2026 wurde die tatsächliche Resolver-Klasse aus dem Distributionspaket 1.0.11 mit kontrollierten Ersatzobjekten für Shopwares Resolver, Konfiguration und Weiterleitungssuche geprüft. Alle neun Prüfungen waren erfolgreich.

Geprüft wurden eine aktive kanonische Seite, eine bestehende Shopware-Weiterleitung, eine aufgelöste Plattformroute, ein deaktiviertes Plugin, die Startseite, eine unbekannte Adresse, eine direkte Selbstweiterleitung und zwei Schreibweisen eines Kategorieziels. Außerdem wurden Sprache, Verkaufskanal und der deaktivierte globale Fallback beim Suchaufruf geprüft.

Dies sind isolierte Codeprüfungen. Sie ersetzen keine vollständigen Shopware-Integrationstests, Datenbanktests oder Prüfungen in der Storefront eines Händlers. Die Fallstudie belegt keinen Kundenumsatz, Rankinggewinn oder Performance-Benchmark.

Was die neun Resolver-Tests tatsächlich abdecken

Die neun bestandenen Prüfungen im Bericht vom 8. September für Version 1.0.11 lassen sich so gruppieren. Damit wird sichtbar, welche Fehlerfälle geprüft wurden:

3 · Bestehende Shopware-Routen

Eine kanonische Seite, ein bestehendes Shopware-Redirect und eine bereits aufgelöste Plattformroute behalten das Ergebnis der Plattform.

3 · Situationen ohne Weiterleitung

Ein deaktiviertes Plugin, die Startseite und eine unbekannte Adresse ohne Treffer dürfen keine neue Produktregel auslösen.

3 · Ziele und Pfade

Eine direkte Selbstweiterleitung wird ignoriert. Ein Kategorieziel und die Variante mit führendem Schrägstrich werden getrennt geprüft.

Die historischen Resolver-Tests verwenden Test-Doubles. Der gesonderte Kompatibilitätsbericht vom 16. September dokumentiert Prüfungen installierter Shops mit Shopware 6.7.14.1 und 6.6.10.25. Beide Berichte helfen, die Nachweise vor Tests im eigenen Shop einzuordnen.

1.0.11 · Resolver · 2026-09-08 (JSON) · 1.1.0 / 0.1.2 · Shopware · 2026-09-16 (JSON)

Mehr zu Magento-2-Modulen und Schnittstellen und WooCommerce-Entwicklung.

Was das für ein individuelles Shopware-Projekt zeigt

Die Arbeit verbindet Ereignisse im Produktlebenszyklus, SEO-Routing, Speicherung, Administration und eine Storefront-Funktion. Derselbe technische Ansatz hilft, wenn eine individuelle Shopware-Anforderung mehrere Teile der Plattform betrifft.

Ein Projekt kann mit der konkreten Regel, Schnittstelle oder Betriebsaufgabe beginnen, die Sie lösen möchten. Unterstützte Versionen, betroffene Verkaufskanäle, Abnahmeprüfungen und Übergabe lassen sich vor Entwicklungsbeginn festlegen.

Quellen und Umfang

Geschrieben vom Entwickler von Product 404 Redirects. Die aktuellen Angaben wurden mit den Paketen 1.1.0 und 0.1.2, ihren Changelogs und Tests auf Shopware 6.7.14.1 und 6.6.10.25 abgeglichen. Der ältere Resolver-Bericht behält Datum und Versionsnummer 1.0.11. Prüfen Sie Antwort und Ziel in Ihrer eigenen Umgebung.

Über Ihr Shopware-Projekt sprechen

Nennen Sie Ihre Shopware-Version, die relevanten Verkaufskanäle und die konkrete Aufgabe. Dann können wir den nächsten Schritt eingrenzen.