Zum Inhalt

Troubleshooting – Stock Alert

Formular erscheint nicht bei ausverkauftem Produkt

  1. Plugin aktiv? Erweiterungen → Meine Erweiterungen → Stock Alert.
  2. Konfig: Stock Alert aktiv für den Sales-Channel?
  3. Position in der Konfig – default „unter Buy-Button". Wenn Dein Theme das stark angepasst hat, ggf. „anstelle der Nicht-auf-Lager-Meldung" testen.
  4. Cache leeren + Theme rebuild (bin/build-storefront.sh).
  5. Bestand wirklich auf 0? Manche Themes zeigen „auf Lager" auch bei stock=0, wenn available > 0.

Bestätigungs-Mail kommt nicht an

  1. Allgemeiner Mail-Versand funktioniert? (Test mit Standard-Bestellbestätigung.)
  2. Spam-Ordner prüfen – Plugin-Mails landen manchmal dort, besonders bei selbst-hostenden SMTP-Servern ohne SPF/DKIM/DMARC.
  3. Mail-Template aktiv? Admin → Einstellungen → Shop → E-Mail-Templates → „Stock Alert Confirmation".
  4. Logs: var/log/prod-*.log nach stock_alert durchsuchen.
Bei vielen verlorenen Mails

Wenn Confirmation-Mails häufig ungeöffnet bleiben, prüfe Deine SPF/DKIM/DMARC-Konfig beim Mail-Server. Plugin-Mails werden von Spam-Filtern stärker geprüft als Standard-Bestellbestätigungen.

Verfügbarkeits-Mail wird nicht versandt obwohl Bestand wieder da

  1. Scheduled Tasks aktiv? 

    php bin/console scheduled-task:list
    kommora.stock_alert.check_availability muss active sein.

  2. Scheduler läuft? Auf Production typischerweise via systemd: 

    systemctl status shopware-scheduler

  3. Bestand wirklich ≥ Schwelle? Die Konfig-Option „Verfügbar ab Bestand" prüfen.

  4. Status des Abos: im Admin → Stock Alert → Abonnements → Status muss confirmed sein. Wenn pending (= nicht bestätigt), wird nicht benachrichtigt.

  5. Manuell anstoßen: 

    php bin/console kommora:stock-alert:check-availability
    Wenn das funktioniert, ist der Scheduler das Problem.

Symptom: Klick auf Link führt zu „Token ungültig" oder „Link abgelaufen".

  1. Ablauf-Zeit in der Konfig prüfen – default 48h. Wenn der Kunde nach 3 Tagen klickt, ist der Link abgelaufen.
  2. Plugin-Secret stabil? Wenn das Plugin neu installiert wurde, ändert sich evtl. das Signing-Secret – alte Links werden ungültig.
  3. URL-Encoding-Problem in Custom-Mail-Templates – sicherstellen dass der Token in der Mail nicht URL-encoded gebrochen ist.

Cleanup löscht Abos, die er nicht sollte

Symptom: Bestätigte Abos verschwinden zu früh aus der Liste.

  1. „Bestätigte Abos behalten (Tage)" in der Konfig prüfen – default 365.
  2. „Auto-Cleanup nach Versand (Tage)" – versendete Abos werden default nach 30 Tagen gelöscht (für Statistik aber reicht das meist).
  3. Manuelles Cleanup läuft sonntags 03:30 – manuell anstoßen für sofortigen Test: 
    php bin/console kommora:stock-alert:cleanup --dry-run

Dashboard zeigt keine Daten

  1. Mindestens 1 Abo in der DB – sonst gibt es nichts zu zeigen

  2. Geografische Heatmap leer: Geo-Lookup-Provider funktioniert?

    • Default: kostenloser ipapi.co-Provider
    • Bei eigenem Hosting kann ein Firewall-Block den Lookup verhindern
    • In der Konfig auf einen eigenen Provider umstellen

  3. Cache-Problem: bin/console cache:clear

Performance: Cron-Lauf dauert sehr lang

Symptom: Bei großem Shop dauert check-availability mehrere Minuten.

  1. DB-Indexe prüfen: kommora_stock_alert_subscription braucht Index auf (status, product_id).
  2. Frequenz erhöhen: Konfig auf 15 Minuten statt 5 Minuten setzen.
  3. Batch-Verarbeitung: in der Konfig kannst Du die Batch-Größe pro Cron-Lauf reduzieren.

API-Zugriffe scheitern mit 403

  1. OAuth-Token gültig? Mit Shopware-Standard-Auth-Endpoint testen.
  2. ACL-Berechtigung des integration-Users: kommora_stock_alert:read für GETs, kommora_stock_alert:create für POSTs.

Hilfe holen

E-Mail an support@kommora.de mit:

  • Shopware- und Plugin-Version
  • Welcher Workflow nicht funktioniert (DOI, Verfügbarkeits-Mail, Dashboard, …)
  • Aus var/log/prod-*.log die Fehlermeldungen
  • Anzahl Abos in Deinem Shop
  • Screenshot der Konfig