Zum Inhalt

Troubleshooting – Widerrufs-Button

Der Button erscheint nicht im Storefront

Häufigster Fall: Plugin ist aktiviert, aber im Footer/Header taucht kein Button auf.

Checkliste

  1. Plugin-Aktivierung prüfen: Admin → Erweiterungen → Meine Erweiterungen → Widerrufsbutton steht auf „Aktiviert".
  2. Sales-Channel-Konfig prüfen: Plugin-Config → der jeweilige Sales-Channel hat „Widerrufsbutton aktiviert" eingeschaltet.
  3. Platzierung prüfen: mindestens eine der Platzierungs-Optionen (Footer/Header/Account-Menü) muss aktiv sein.
  4. Cache leeren: bin/console cache:clear
  5. Bundle dumpen: bin/console bundle:dump
  6. Theme neu kompilieren: bin/build-storefront.sh
Bei aggressiven Themes (ThemeWare, TWT) zusätzlich

Diese Themes ersetzen den Footer komplett durch eigene Blöcke und rufen die Standard-Shopware-Blöcke nicht mit parent() auf. Das Plugin hat dafür einen JS-Fallback (seit 1.1.2): wenn der Twig-Override nicht greift, fügt ein kleines Script den Button per CSS-Klassen-Anker in den Footer-Hotline-Bereich ein.

Funktioniert nicht? Prüfe: ist das Storefront-JS-Bundle (src/Resources/app/storefront/dist/storefront/js/kommora-withdrawal-button/kommora-withdrawal-button.js) nach dem Theme-Build vorhanden?

Bei aggressiv überschriebenen Themes (ThemeWare TWT, MAN-Shop, Opel-Collection, BPW, TÜV-Shop, ledclusive) entfernt das Theme nach Page-Load aktiv DOM-Knoten aus den Footer-Spalten. Das Plugin nutzt seit 1.4.x mehrstufige Fallback-Strategien:

  1. Tier 1a: Admin-konfigurierter Custom-CSS-Selektor (höchste Priorität, siehe Plugin-Config → Darstellung)
  2. Tier 1b: .footer-contact-form (LED/ledclusive-Pattern, seit 1.4.3)
  3. Tier 2: .footer-column-hotline (Shopware-Standard)
  4. Tier 3: Heading-Text-Suche im Footer („Hotline", „Service", „Kontakt", …)
  5. Tier 4: letztes .footer-column-content-inner
  6. Tier 5: Body-Sibling nach <footer> (theme-unabhängig)

Plus: Visibility-Probe (500 ms nach Inject), Body-Level-MutationObserver und 6 Retry-Zeitpunkte (1.5 s, 3 s, 5 s, 7.5 s, 10 s, 15 s) decken Theme-Cleanup-Fenster ab.

Wenn der Button trotzdem nicht erscheint:

  1. Im Plugin-Config unter Darstellung → Eigener CSS-Selektor für Footer-Anker den Selektor eines stabilen Footer-Containers angeben (z. B. .footer-contact-form bei ledclusive).
  2. Browser-DevTools-Console öffnen — wenn JS-Errors vor unserem Script den Page-Load brechen, läuft unser Inline-JS nicht.
  3. curl https://shop.tld/ | grep -c kommora-withdrawal-footer-link — muss mind. 2× Treffer geben (Marker + Klassenname im Inject-Code).
  4. Bei sehr exotischen Themes: support@kommora.de mit DevTools-Output des Footer-Bereichs anschreiben.

Admin-Menü-Eintrag „Widerrufsbutton" fehlt unter Bestellungen (6.5/6.6)

Auf Shopware 6.5 und 6.6 wird das Admin-Modul aus dem vorkompilierten Webpack-Bundle geladen (src/Resources/public/administration/js/kommora-withdrawal-button.js). Wenn diese Datei im ZIP fehlt, wird das Modul ohne sichtbaren Fehler nicht registriert — Menü-Eintrag verschwindet.

Symptom: Plugin aktiviert, im Backoffice unter „Bestellungen" fehlt der Punkt „Widerrufsbutton".

Diagnose: unzip -l KommoraWithdrawalButton-X.Y.Z.zip | grep public/administration/js muss kommora-withdrawal-button.js (≈ 60 KB) liefern.

Fix: Auf 1.3.3+ updaten (dort wurde das verlorene Bundle wieder ins ZIP gelegt). Auf Shopware 6.7 fällt das Problem nicht auf, weil Vite zur Laufzeit kompiliert.

HTTP 500 beim Klick auf den Button

In Sub-Directory-Installs (https://shop.tld/subverzeichnis/public/) konnte es in älteren Versionen passieren, dass der Button auf https://shop.tld/kommora/withdrawal statt https://shop.tld/subverzeichnis/public/kommora/withdrawal zeigte → HTTP 500.

Fix: seit Version 1.1.7 erzeugt das Plugin die URL über den Shopware-Router, der Basis-Pfad wird automatisch berücksichtigt.

Wenn Du auf 1.1.7+ bist und der Fehler trotzdem auftritt:

  • Cache leeren
  • bin/console route:debug | grep kommora ausführen – die Route frontend.kommora.withdrawal.form muss erscheinen
  • nginx/Apache-Rewrite-Konfig prüfen (Standard-Shopware-Rewrite-Rules sind erforderlich)

„Bestellung nicht gefunden" beim Gast-Widerruf

Der Gast-Verbraucher gibt Daten ein, bekommt aber „Bestellung nicht gefunden" zurück.

Standard-Modus (Shopware-Bestellnummer)

  1. Stimmt die E-Mail genau mit der hinterlegten order.orderCustomer.email überein? Tippfehler?
  2. Stimmt die Bestellnummer (mit/ohne Präfix)? Im Admin im Bestellmodul nachsehen.
  3. Wenn PLZ eingegeben: stimmt sie mit einer der order.addresses[].zipcode?
  4. Bestellung darf nicht bereits widerrufen sein – jede Bestellung kann nur einmal widerrufen werden.

ERP-Modus (Custom Field)

  1. Im Plugin-Config: ist das richtige Custom Field ausgewählt?
  2. Ist im konkreten Order der Custom-Field-Wert befüllt? Admin → Bestellungen → die betreffende Bestellung → Tab „Custom Fields" prüfen.
  3. Fallback aktiv? Wenn der ERP-Wert leer ist, kann der Kunde die Shopware-Bestellnummer eingeben.
  4. Bei der Custom-Field-Suche ist Whitespace-Empfindlichkeit zu beachten – das Plugin macht ein EqualsFilter, nicht Contains. Wenn das ERP-Field manchmal AB-12345 und manchmal AB-12345 (mit Trailing Space) enthält, wird nichts gefunden. Datenbereinigung im ERP nötig.

Bestätigungsmail kommt nicht an

  1. Mail-Versand des Shops generell prüfen – z.B. eine Test-Bestellung machen, ob die Standard-Bestätigungsmail ankommt.
  2. Spam-Ordner prüfen – plugins mit eigenem Template landen manchmal dort.
  3. Mail-Template aktiv? Admin → Einstellungen → Shop → E-Mail-Templates → „Widerrufsbestätigung" → muss aktiviert sein.
  4. Sales-Channel-Zuweisung: das Template muss dem richtigen Sales-Channel zugewiesen sein.
  5. Logs anschauen: var/log/prod-*.log – wenn der Mailer Fehler wirft, steht es dort.
Resend manuell auslösen

Im Admin-Modul Widerrufsbutton → Detail-Seite eines Widerrufs → Aktion „E-Mails erneut senden" verfügbar mit 60-Sekunden-Cooldown. CLI-Variante: bin/console kommora:withdrawal:resend <orderNumber>.

Plugin-Konfig speichert nicht

Wenn Klick auf „Speichern" keine Notification zeigt oder die Werte beim Reload wieder Default sind:

  1. Browser-Konsole öffnen (F12), nach Errors suchen.
  2. Sales-Channel ausgewählt? Oben im Plugin-Config muss ein konkreter Channel (oder „Alle Sales Channels") aktiv sein. Sonst wird der Speichern-Aufruf möglicherweise stumm verworfen.
  3. Admin-User-Berechtigung: Der User braucht die system_config:update-ACL.

Custom-Field-Dropdown bleibt leer (ERP-Modus)

Das Dropdown unter „Custom Field für ERP-/externe Bestellnummer" zeigt keine Auswahl.

Ursache: Es existiert kein Custom-Field-Set, dessen Relation auf entityName = 'order' zeigt.

Lösung:

  1. Einstellungen → System → Custom Fields → Set hinzufügen → Name z.B. erp_data.
  2. Zuweisung → Bestellungen.
  3. Feld hinzufügen → technischer Name, Typ Text.
  4. Speichern.
  5. Plugin-Config neu öffnen → das Field erscheint im Dropdown.
Wenn das Set existiert, das Field aber nicht erscheint

Browser-Cache leeren. Bei Bedarf bin/console cache:clear zusätzlich.

Bestellstatus wechselt nicht auf „Widerrufen"

Wenn Du im Plugin-Config „Automatischer Bestellstatus" aktiv hast, aber die Bestellung nach Widerruf trotzdem den alten Status behält:

  1. State-Machine-Transition prüfen: Der State withdrawn ist nur bei aktivem Plugin registriert. Wurde das Plugin deinstalliert und neu installiert?
  2. Berechtigung des Plugin-Users: Plugin-Aktionen laufen im System-Context, dürfen aber durch eigene ACL-Konfigs blockiert sein.
  3. Konkurrenz mit anderen Plugins: Andere Bestell-Plugins können die State-Machine-Transition stören. In var/log/prod-*.log nach state_machine_transition suchen.

Performance: Auswahl-Dropdown lädt langsam

Bei Kunden mit sehr vielen Bestellungen (>500) kann das Dropdown initial 1-3 Sekunden brauchen.

Linderung: Im Plugin-Config eine reasonable „Widerrufsfrist (Tage)" einstellen (z.B. 14). Damit reduziert das Plugin die Vorab-Filterung auf einen realistischen Zeitraum.

Hard-Limit: Das Plugin lädt maximal die letzten 50 Bestellungen des Kunden für die Eligibility-Prüfung. Bei mehr als 50 alten Bestellungen sieht der Kunde im Dropdown nur die jüngsten – kann aber für ältere weiterhin direkt die Bestellnummer per Deep-Link aufrufen (/kommora/withdrawal?orderNumber=...).

Tests im Stage-System: keine echten Mails versenden

Im Stage-System sollst Du testen können, ohne dass echte Kunden-E-Mails rausgehen.

  1. Symfony-Mailer auf null:// stellen (Stage-.env: MAILER_DSN=null://null) – Mails werden geloggt, aber nicht versendet.
  2. Mail-Template-Empfänger temporär überschreiben – im Plugin-Config „Interne Benachrichtigungs-E-Mail" auf eine Stage-Adresse setzen, Kunden-Mail-Template inhaltlich deaktivieren.
  3. Plugin-Konfig pro Sales-Channel pflegen – auf dem Stage-Sales-Channel andere Empfänger als auf Production.

Hilfe holen

Wenn keiner der Punkte hilft: E-Mail an support@kommora.de mit:

  • Shopware-Version
  • Plugin-Version
  • Beschreibung des Verhaltens
  • Inhalt aus var/log/prod-<datum>.log rund um den Fehlerzeitpunkt
  • Screenshots (Plugin-Konfig und konkrete Fehlermeldung)

Antwortzeit: 1 Werktag.