// Shopware-Hilfe
Bestellmails kommen erst nach Stunden, die Sitemap ist veraltet, Vorschaubilder werden „generiert“ und nie fertig, in den FroshTools steigen „Open Queues“ und „Scheduled Tasks Overdue“? Dahinter steckt fast immer dieselbe Ursache: Die Warteschlange von Shopware wird nicht zuverlässig im Hintergrund abgearbeitet.
Shopware 6 erledigt viele Aufgaben nicht sofort, sondern über eine Warteschlange, die Message Queue: Mails, Indexierung, Vorschaubilder, Sitemap, Importe und Exporte. Geplante Aufgaben, die Scheduled Tasks, legen in festen Abständen weitere Aufträge in diese Warteschlange. In einer Standardinstallation arbeitet der Admin-Worker die Warteschlange ab, und zwar nur, solange jemand in der Administration eingeloggt ist. Für einen Shop im Betrieb gehört das auf den Server: ein CLI-Worker für die Warteschlange, ein Prozess für die geplanten Aufgaben, und erst danach wird der Admin-Worker abgeschaltet.
// Ursachen
Ohne eigene Konfiguration arbeitet der Admin-Worker im Browser. Ist niemand eingeloggt, bleibt alles liegen. Sind viele eingeloggt, erzeugt jede offene Administration zusätzliche Last.
Der Admin-Worker wurde deaktiviert, aber kein CLI-Worker eingerichtet. Dann steht die Warteschlange komplett still, ohne Fehlermeldung im Shop.
Der Worker arbeitet nur ab, was in der Warteschlange liegt. Damit geplante Aufgaben wie die Sitemap überhaupt dort landen, muss zusätzlich der Scheduler regelmäßig laufen.
Der Worker bricht mit „Allowed memory size exhausted“ ab oder wird vom Hoster nach kurzer Zeit beendet. Große Indexierungen oder Thumbnail-Läufe bleiben dann hängen.
Der Cronjob ruft eine andere PHP-Version auf als die Website, etwa eine ältere Standardversion des Servers. Dann scheitert er still oder mit Fehlern im Log.
Ein Plugin oder eine geplante Aufgabe wirft bei jedem Versuch einen Fehler. Die Nachricht wird wiederholt und landet schließlich in der Fehler-Warteschlange, die niemand prüft.
Dafür brauchen Sie Zugriff per SSH oder auf die Cronjobs Ihres Hosters. Die Reihenfolge ist wichtig: erst Worker und Scheduler einrichten und prüfen, dann den Admin-Worker abschalten. Sonst steht die Warteschlange still.
1. Warteschlange abarbeiten. Der Worker läuft dauerhaft als Dienst, etwa über Supervisor oder systemd, oder als Cronjob jede Minute mit Zeitlimit:
php bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=512MBei älteren Shopware-Versionen ohne die Warteschlange low_priority genügt async.
2. Geplante Aufgaben einplanen. Der Scheduler legt fällige Aufgaben in die Warteschlange, ebenfalls als Dienst oder jede Minute per Cronjob:
php bin/console scheduled-task:run --time-limit=60 --memory-limit=512M3. Prüfen. Nach einigen Minuten müssen die offenen Aufgaben sinken und eine Testmail ohne geöffneten Admin ankommen. Ab Shopware 6.7.2 zeigt bin/console scheduled-task:list den Zustand der geplanten Aufgaben direkt an.
4. Admin-Worker abschalten. Erst jetzt in config/packages/shopware.yaml eintragen und anschließend den Cache leeren:
shopware:
admin_worker:
enable_admin_worker: falseIm Cronjob immer den vollständigen Pfad zur PHP-Version der Website verwenden, nicht einfach php. Nach jedem Shopware- oder Plugin-Update die Worker mit bin/console messenger:stop-workers neu starten lassen, damit sie den neuen Code verwenden.
Wenn Sie keinen SSH-Zugang haben, wenn die offenen Aufgaben trotz Worker weiter steigen oder wenn im Log immer wieder dieselben Fehler auftauchen. Wir richten Worker und Scheduler als Dienst auf Ihrem Server ein, prüfen die Fehler-Warteschlange und sorgen dafür, dass es nach Updates weiterläuft. Das gehört bei uns zu Server & Hosting und zur laufenden Wartung.
// Soforthilfe
Schicken Sie uns kurz, was liegen bleibt und wo Ihr Shop gehostet ist. Wir richten Worker und geplante Aufgaben so ein, dass sie dauerhaft laufen, auch nach Updates.
// Häufige Fragen
Der Admin-Worker arbeitet die Warteschlange von Shopware im Browser ab, solange jemand in der Administration eingeloggt ist. Für Testsysteme reicht das, für einen Shop im Betrieb nicht, weil ohne eingeloggte Mitarbeiter nichts passiert.
Nur wenn vorher ein CLI-Worker und der Scheduler auf dem Server laufen. Sonst arbeitet niemand mehr die Warteschlange ab, und Mails, Indexierung und Sitemap bleiben komplett liegen.
Der Worker verarbeitet nur, was in der Warteschlange liegt. Fällige geplante Aufgaben legt erst scheduled-task:run dort hinein. Beide Prozesse müssen laufen.
Ein dauerhaft laufender Dienst über Supervisor oder systemd reagiert sofort und ist die saubere Lösung. Auf Hosting ohne eigene Dienste ist ein Cronjob jede Minute mit Zeitlimit ein guter Ersatz.
Dem PHP-Prozess ist der Speicher ausgegangen, oft bei großen Indexierungen oder Thumbnail-Läufen. Abhilfe schaffen ein passendes --memory-limit, ein höheres PHP-Speicherlimit für die Kommandozeile und kleinere Stapel.
Für die meisten Shops reicht die Datenbank. Bei großen Katalogen, vielen Bestellungen oder parallelen Importen kann ein eigener Transport wie Redis oder RabbitMQ die Datenbank entlasten.
Ja. Laufende Worker verwenden noch den alten Code. Mit bin/console messenger:stop-workers beenden sie sich sauber und werden vom Dienst oder beim nächsten Cronjob neu gestartet.