Selbes Ergebnis 
Danke schonmal fürs anschauen. Noch eine Idee? 
Ich habe jetzt nach Konsultation der Doku Message Queue - Shopware Developer das hier probiert
unterverzeichnis/bin/console messenger:consume-messages --time-limit=300 --memory-limit=1G
Leider das gleiche negative Ergebnis
Manchmal hilfts, dem messenger:consume-messages ein -vvv mitzugeben. Dann bekommt man eventuelle Fehlermeldungen beim Abarbeiten mit. Ich hatte mal in einer der frühen SW6 Versionen das Problem, dass hier eine Exception auftrat und eine weitere Verarbeitung verhindert hat.
Edit: Natürlich hab ich das in der Konsole gemacht.
In der konsole (putty) bin ich im „bin“ Verzeichnis. Wenn ich den direkten Aufruf von
console messenger:consume-messages --time-limit=300 --memory-limit=1G
versuche, kommt als Antwort „command not found“. console ist aber im Verzeichnis. Fühle mich ziemlich DAU. Was mache ich falsch?
UPDATE: Hüstel. muss ja php vorne dran stellen. Hier kommt mein anderes Problem. Ich kann in meiner Provider Umgebung (Plesk) keine php Kommandos ausführen. Da fehlt wohl eine Installation
Ich denke es muss nur consume (ohne „-messages“) heißen. Und ich muss bei den Konsolen-Befehlen immer die php-Version voranstellen. Der gesamte Befehl sieht dann so aus:
/usr/bin/php7.4-cli bin/console messenger:consume --time-limit=300 --memory-limit=1G
Vielen Dank für den Tipp.
Bei mir hat’s mit dem Befehl bin/console messenger:consume --time-limit=300 --memory-limit=1G funktioniert.
Aber wenn du nur bin/console eingibst, bekommst du ne Übersciht der Befehle
ich habe einfach das Problem, dass wohl bei meinem Server PHP nicht installiert ist. Ich versuche erstmal, das mit meinem Provider zu klären.
Das freut mich das es funktioniert hat. Natürlich für die Leute die jetzt nicht so sehr auf der console arbeiten, kann ich nur den Parameter „-h“ am Ende noch einmal ans Herz legen der erklärt was für Parameter der Command hat und was diese auch tun. Nicht jede Umgebung wird 1GB RAM haben befürchte ich. Daran habe ich am Anfang nicht gedacht. Das ist tatsächlich aber auch nur eine Überprüfung wenn ein „Job“ abgearbeitet wurde, ob der RAM bereits benutzt wird.
PHP wird schon installiert sein, sonst würde dein Shop nicht laufen. Es wird vermutlich nur daran liegen das der Pfad zu PHP anders ist. Wenn ich mich recht entsinne sieht der bei Plesk eher so aus:
/opt/plesk/php/7.4/bin/php [der konsolen befehl].
Ansonsten wenn du Zugang per SSH hast kannst du auch einmal „which php“ in die Console eingeben, dann siehst du den Verzeichnispfad.
Aber Achtung: Der „Default“ kann etwas anderes sein als das was du für deinen Shop in Plesk konfiugriert hast als PHP Version. Plesk unterstützt halt mehrere und verändert nicht den Default auf der Konsole. Das muss man wissen wenn man damit Dinge tun möchte
1 „Gefällt mir“
wenn ich im root verzeichnis which php eingebe, kommt die selbe Fehlermeldung 
Bin mit Putty per SSH drauf.
PHP ist natürlich drauf, sogar einieg Versionen. Aber CLI Kommandos funktionieren nicht
bei mir hat es auch über den Cronjob funktioniert, danke für die Hilfe !
Hallo,
Bei mir hat es mit SW5 noch funktioniert mit den Mails, doch mit SW6 geht es mir ähnlich wie euch. Hab auch schon mal eine Neu-Installation probiert und mir wurde geraten alle Einstellungen nochmal zu checken aber danach auch kein Erfolg. Jetzt hoffe ich mal das ich mit euren Tipps etwas mehr Erfolg habe, sonst bin ich echt verzweifelt 
Ich habe den Befehl … messenger:consume -vv laufen lassen. Der Versand funktioniert nicht und bekomme folgende Meldung:
[OK] Consuming messages from transports „default“.
// The worker will automatically exit once it has received a stop signal via the messenger:stop-workers
// command.// Quit the worker with CONTROL-C.
09:17:12 INFO [messenger] Received message Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage [„message“ => Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage^ { …},„class“ => „Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage“]
Ist eventuell die extrem langsame Indexierung verantwortlich?
Edit: Tatsächlich lag die Ursache in der Indexierung (~29.000 Seiten). Nach Änderungen in der php.ini und Seiten-Indexierung wurden alle Testmails der letzten Tage gesendet.
Das ist leider von Fall zu Fall unteschiedlich. Grundsätzlich wird alles verarbeitet (oder versucht zu verarbeiten) aus der „enqueue“ Tabelle. Man kann auch mehrere Prozesse parallel starten.
Ansonsten vielleicht hier noch ein Update weil es im Shopware Slack auch gestern Ein Thema gab, welches hier rein passt.
Demnach wird es zukünftig wieder synchron laufen, und man kann im Zweifel aktuell mit der ANpassung an der framework.yaml dasselbe Resultat erzielen.
Ich hatte heute einen Kampf mit den E-Mail Templates.
Die Lösung des ganzen war ganz einfach: Die verwendeten Variablen müssen sowohl im Text als auch HTML Format vorhanden sein.
Im Textbereich hatten wir z.B. {{ order.orderNumber }} vergessen. Dieser war aber im HTML Bereich. Dadurch haben keine Kunden Bestellbestätigungen erhalten.
Doof und einfach…hat uns viel Zeit gekostet um es zu finden und verstehen.
Hoffe das hilft dem einen oder anderen
1 „Gefällt mir“
Es ist zum Verzweifeln finde den Fehler leider nicht.
ionos > Synchroner Mailversand und Asynchroner Mailversandfunktionieren nicht.
über putty mit protokoll (-vv)
(uiserver):xxx:~$ /usr/bin/php7.4-cli /kunden/homepages/xxx/htdocs/TestShop/bin/console messenger:consume --time-limit=300 --memory-limit=256M -vv
[OK] Consuming messages from transport „default“.
// The worker will automatically exit once it has exceeded 256M of memory, been running for 300s or received a stop
// signal via the messenger:stop-workers command.
// Quit the worker with CONTROL-C.
18:52:08 INFO [messenger] Received message Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask [„class“ => „Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask“]
18:52:08 INFO [messenger] Message Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask handled by Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTaskHandler::__invoke [„class“ => „Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask“,„handler“ => „Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTaskHandler::__invoke“]
18:52:08 INFO [messenger] Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask was handled successfully (acknowledging to transport). [„class“ => „Shopware\Core\Content\ProductExport\ScheduledTask\ProductExportGenerateTask“]
es war scheinbar ein Variabel Fehler
wo es heißen sollte
Viele Grüße nach Wien
Viele Grüße nach {{customer.addresses.at(0).city}}
Nachdem ich es aus dem E-Mail-Templates für die Fußzeile gelöscht habe ging es wieder.
Was ist daran falsch?
Viele Grüße in deine Heimat
Hi,
{order.billingAddress.city}?
PS: Sorry, hab gerade erst gesehen das es um die Fußzeile geht…wenn man es direkt in die jeweiligen Mails einfügt, klappt order.billingAdress.city gut.