https://developers.gambio.de/docs/3...ference/cronjobs/set-image-processing-trigger cronjobs/image_processing Wenn ich diesen Befehl per POST sende, kommt eine Fehlermeldung zurück: { "code": 415, "status": "error", "message": "Unsupported Media Type HTTP", "request": { "method": "POST", "url": "https://www.realrecyclers.com", "path": "/api.php/v2/cronjobs/image_processing", "uri": { "root": "/api.php", "resource": "/v2/cronjobs/image_processing" } } } Ich sende, wie bei allen anderen (normal funktionsfähigen) API Requests einen cURL Request --request POST --user (mit meinen User-Daten) --url https://www.realrecyclers.com/api.php/v2/cronjobs/image_processing Warum dann der Fehler "Unsupported Media Type HTTP"??? Bin noch auf Shop-Version 3.14.3.0, der Befehl sollte doch aber schon in der 3.14er Version vorhanden sein (lt. Doku).
Hallo, laut der Dokumentation kannst du keinen User direkt übergeben, sondern musst ein Header senden: Code: curl --request POST \ --url https://gambio-shop.de/shop1/api.php/v2/cronjobs/image_processing \ --header 'authorization: Basic REPLACE_BASIC_AUTH' \ --header 'content-type: application/json' Übergebe daher bitte Basic authorization als Header
??? Äh, wie? Danke für die schnelle Antwort, Till, aber bei allen bislang von mir erfolgreich genutzten API Aufrufen nutze ich den User-Aufruf. Aber Deine Antwort hat mich in die richtige Richtung gewiesen: --request POST --user (mit meinen User-Daten) --header 'content-type: application/json' --url https://www.realrecyclers.com/api.php/v2/cronjobs/image_processing --header 'content-type: application/json' muss zwingend hinten dran. Hatte ich vergessen. Gibt es da eigentlich irgendwelche versteckte Parameter? An und für sich würde ich nur gezielt das image-processing der Bilder eines bestimmten Produkts anstupsen. Wenn ich einem bestehenden Produkt die Bilder im original_images-Verzeichnis austausche, sollte dies gleich im Shop sichtbar sein, ohne auf den täglich ausgelösten cronjob zu warten oder manuell alle Bilder "image-zu-prozessen" - was bei tausenden Bildern ja lange dauert.
Aber wie sehen ich nun eigentlich, ob der Befehl ausgeführt wird? Hab den geschickt - aber in den Logs ist nichts neues. Der nächtliche Cronjob ist dort zu finden: [2021-04-29 00:00:25] ImageProcessingCronjob.INFO: Image Processing {"total image count":4017,"last image number":1} [] Wenn ich den Cronjob jetzt per API triggere, müsste der nicht dann auch gleich in den Logs auftauchen? Und: Ich nehme an (wenn es denn funktioniert), dass der API-Getriggerte Cronjob mit den Einstellungen läuft, die man unter "zeitgesteuerte Aufgaben" gemacht hat?
Also na einer knappen Stunde ist noch nix im LOG aufgetaucht, ich habe jetzt mal testweise eine neue Datei in den original images Ordner gelegt und das image-prozessing per API erneut getriggert. Die response die nun kommt ist o.k.: { "code": 200, "status": "success", "action": "setImageProcessingTrigger" } Jetzt muss es nur noch funktionieren....
Also nach mehreren Versuchen: Ich kann den Befehl schicken. Ich bekomme eine "success"-Resonse der API. Der Befehl wurde also erfolgreich geschickt. Aber: nicht ausgeführt. Ich habe eine neue Datei in den original-images-Ordner gelegt. Diese sollte doch nach Ausführen des Image-Prozessing dann entsprechend in den anderen Verzeichnissen wie "info_images" oder "thumbnail_images" erscheinen, oder? Tut sie aber leider nicht. Wenn ich den Cronjob bei Estugo in den "Geplanten Aufgaben" manuell auslöse, dann... taddaaa, passiert auch nix???? Wenn ich das Image-Prozessing manuell starte, dann wird das Bild korrekt behandelt. Hab ich da einen Denkfehler?
Also, das wird ja interessant... Wenn ich den Cronjob in Estugo manuell auslöse, ist dieser nach 21 Sekunden fertig. Im Log stehen dann aber Fehler, nach jedem Auslösen wird ein anderes Bild als "unprocessable" angezeigt. Die Bilder die moniert werden funktionieren aber im Shop problemlos. Ich sehe also: - Auslösen des Image Prozessing per API macht schlich: Nichts. - Manuelles Auslösen des Cronjobs bei Estugo funktioniert nicht, weil Fehler auftauchen, die aber wohl keine sind. - Manuelles Image-Prozessing im Shop-Backend ist laaaangsam und nach einem gewissen Timeout wird das auch abgebrochen, wenn ich eingeloggt bin aber nichts mache. Ich hätte gerne die Möglichkeit, das Image-Prozessing funktionierend bei Bedarf zu triggern. Ist das aussichtslos?
Nachdem die fraglichen Bilder beim Image Processing direkt aus dem Shop keine Probleme machen und die Bilder so um die 200 kB haben - nein. Die Bilder sind so gewöhnlich wie alle anderen auch.
Ich bekomme da irgendwie keine vernünftige Lösung hin. Der API-Trigger läuft wohl nicht so wie er soll, als Cronjob macht es auch Probleme (siehe hier)... Ich denke ich werde mir was programmieren, das mir hier lokal in der Warenwirtschaft die Bilder automatisch in die notwendigen Formate konvertiert für die Thumbnails, Info Images etc., vielleicht bekomme ich sogar einen automatiuschen Upload in die entsprechenden Shop-Verzeichnisse hin. Das Image-Prozessing ist für meine Anwendung hier wohl zu unflexibel. [Was ich noch herausbekommen muss ist: Was passiert mit den alten Bildern, die ja im Shop-Cache sind? Wenn ich ein Wenn ich ein bereits vorhandenes Bild ändere, dessen Dateiname aber identisch bleibt, will ich ja nicht, dass das alte Bild aus dem Cache ausgeliefert wird. Sondern das neue. Weiss jemand ob das ImageProzessing den Cache auch gleich mit ändert?] Wenn ich es gerade richtig gesehen habe, wird da ja (logischerweise) nix ge-cached bei den Bildern. Sollte also kein Problem sein.