ich arbeite gerade an der Migration eines bestehenden Magento 1.9 Shops. Der Migration Wizard übernimmt Produkte, Bestellungen und Kunden ohne Probleme, nur bei den Bildern gibts Probleme. Von den insgesamt ca. 2200 Bildern werden nur ca. 800 übernommen. Die Tabelle "swag_migration_media_file" führt alle Einträge auf, aber nur ein geringer Teil wird ordnungsgemäß verarbeitet (processed = 1). Wenn ich den Migration Wizard immer wieder laufen lasse, werden ab und an ein paar Einträge auf “processed = 1” gesetzt und die Bilder übernommen. Mir ist nicht klar, wie ich diesen Prozess beschleunigen / debuggen kann. Offensichtlich passiert irgendwo ein Abbruch / Timeout, im Log des Migration Run steht aber, es sei alles in Ordnung?
Die Migration der Bilder läuft über einen Hintergrundsprozess und wird darüber abgearbeitet.
Dieser läuft nur durch, wenn entweder ein Bentuzer im Admin eingeloggt ist, oder wenn man den CLI-Befehl “bin/console messenger:consume” ausführt (der “-vv” Paramter macht sichtbar, welche Nachrichten abgearbeitet werden). Probiere es bitte mit dem CLI-Befehl, ansonsten müsste man im “SwagMigrationAssistant\Migration\MessageQueue\Handler\ProcessMediaHandler” debuggen, ob ein 500er auffällt.
vielen Dank - leider passiert beim Aufruf des Kommandos gar nichts, es werden weder Bilder in der Tabelle swag_migration_media_file verarbeitet, noch bekomme ich irgendeinen Status zurück. Es wird auch kein Fehler geschmissen. Bin ehrlicherweise etwas ratlos. Wenn ich die Migration manuell übers Backend wiederholt aufrufe, werden wieder 10 - 20 Bilder verarbeitet und dann ist wieder Schicht im Schacht.
Muss der Befehl "“bin/console messenger:consume” generell regelmäßig via Scheduler / Cronjob aufgerufen werden? Wie spielt das mit “schedule:run” zusammen?
Es scheint da generell noch ein paar Bugs zu geben, es wird beispielsweise der Alt-Text des Bildes von Magento automatisch als “file_name” übernommen - aber nicht Url-Encoded, was dazu führt, dass plötzlich Dateinamen wie bspw. “Kassentisch “Zero” groß, Dekor Holzleisten” generiert werden - das führt wohl zu Problememn, da das System die Pfade nicht auflösen kann. Kann man die automatische Umbenennung der Files in Shopware nicht beeinflussen bzw. aus meiner Sicht kann das so ja gar nicht funktionieren?
wir holen uns die Pfade zu den Bildern aus der ‘catalog_product_entity_media_gallery’-Tabelle und strippen uns dann den Filenam aus dem Pfad heraus, dies sollte dann ohne Probleme funktionieren…
Wie schon angesprochen könntest du debugg mäßig dich an dem try-catch vom “SwagMigrationAssistant\Migration\MessageQueue\Handler\ProcessMediaHandler” dranhängen und schauen, ob hier ein weiterer Fehler auftaucht (wichtig hierbei ist nur: Du bekommst per print_r oder ähnliches keine Ausgabe, nutz hierfür den error_log-Befehl).
Im ‘Swag\MigrationMagento\Profile\Magento\Media\LocalMediaProcessor’::persistFileToMedia kann man die Namensgebung anpassen.
Leider hilft mir das nicht weiter, in meiner Tabelle “swag_migration_media_file” sind die Dateinamen unter “file_name” nicht jene aus der Magento Tabelle, sondern er nimmt den Beschreibungstext als Basis
Offensichtlich hängt das ganze dann mit dem Thumbnail Service zusammen, da dieser diese Dateinamen logischerweise nicht findet und es zu einem Fehler kommt. Ich habe jetzt mal den Pfad im ThumbnailService.php mit error_log ausgegeben, im messsage:consume sieht das dann so aus:
09:05:19 INFO [messenger] Received message Shopware\Core\Content\Media\Message\GenerateThumbnailsMessage [“message” => Shopware\Core\Content\Media\Message\GenerateThumbnailsMessage^ { …},“class” => “Shopware\Core\Content\Media\Message\GenerateThumbnailsMessage”]
media/c3/88/98/1595322303/Anwendungsbeispiel für Kleiderschrank.jpg
Warning: exif_read_data(): Unable to open file in /PATH_TO_INSTALLATION/vendor/shopware/core/Content/Media/Thumbnail/ThumbnailService.php on line 245
Aus meiner Sicht gibt es da schon einen Bug bei den extrahierten Dateinamen aus Magento - zur Info: ich verwende Shopware 6.2.3 und die aktuellste Version des Migration Wizard.
In der Tabelle swag_migration_media_file sieht der Datensatz nämlich so aus:
uri: /media/catalog/product/2/0/2001701b_2.jpg
/* diese Datei existiert im Magento File System */
file_name: Anwendungsbeispiel für Kleiderschrank
daraus wird offensichtlich der neue Dateiname für SW 6 generiert, aber eben mit Leer- und Sonderzeichen - und das dürfte dann zu den Problemen führen - oder verstehe ich da was falsch?
Ich bin wirklich interessiert daran, dass wir da weiterkommen, meine Agentur migrieren derzeit 2 Magento 1.9 Projekte auf SW 6 - ich hoffe, dass wir da zu einer Lösung kommen. Ich habe den Shop mittlerweile komplett neu aufgesetzt, den Migration Wizard auf dem blanken System laufen lassen - das Verhalten ist das gleiche
Konnte das Problem weiter eingrenzen: die Dateien werden in Shopware ja im /media Ordner abgelegt, dort werden allerdings Sonderzeichen und Umlaute nicht korrekt abgebildet und statt bspw. „groß.jpg“ haben wir dann „gro??.jpg“ im Filesystem - und schon kracht es
den Fehler haben wir schon bei uns identifiziert und auch gelöst, der Bugfix hierfür kommt in dem nächsten Release des Magento-Profils.
Wenn du nicht solange warten kannst / willst, könntest du temporär den LocalMediaProcessor wie in der aktuellen GitHub-Version umbauen:
der Fix im LocalMediaProcessor hat die Situation verbessert, immerhin bekomme ich jetzt ca. 50% meiner Dateien inital in den „processed“ Status. Bei der Generierung der Thumbnail bekomm ich in der Message Queue aber immer wieder Warnings nach dem Schema:
Warning: exif_read_data(): Unable to open file in /XXXXXX/vendor/shopware/core/Content/Media/Thumbnail/ThumbnailService.php on line 243
Die Files sind aber da, aber der Fix generiert Pfade wie bspw. sowas:
_media/63/1b/g0/1595332010/_Konfektionsrahmen nach Maß_1920x1920.jpg
Dann kommt es beim ThumbnailService zu einem Fehler:
Warning: exif_read_data(): Unable to open file in /XXXXXX/vendor/shopware/core/Content/Media/Thumbnail/ThumbnailService.php on line 246
Das liegt daran, dass der Fix von euch Sonderzeichen (?) und Leerzeichen in den Dateinamen belässt und es so wieder zu falschen Pfaden kommt, weil das im Dateisystem so abgelegt wird:
habs jetzt endlich zum Laufen gebracht - das Problem lag wirklich an den ungültigen Filenamen - ich habe einen Pull Request erstellt, damit laufen bei mir alle 2400 Dateien ohne Probleme durch
danke für deinen PR, werden die Änderung von dir übernehmen und auch bei uns im Shopware-Migrationsprofil nutzen (hier könnte der Fall theoretisch auch auftreten). Die Änderung wird in den nächsten Versionen der Plugins enthalten sein und ist jetzt schon auf github verfügbar.
