@SebastianKlöpper Ich habe gerade einen weiteren Test gemacht. Unser “Katalog” (also Shop Nr. 2) läuft in identischer Umgebung bei All-Inkl., gleicher Account, gleiche Umgebung, gleiches PHP - nur SW ist noch 5.2.9 - und dort kann ich nach wie vor Bilder hochladen und sehe sofort die Thumbnails. Eine zeitgleiche Änderung bei All-Inkl. kann ich damit nun 100% verneinen, es muss etwas an 5.2.17 sein
Hi,
danke fürs Feedback. Versuchen wir morgen mal weiter nachzugehen, warum genau das nur bei einigen all-inkl Umgebungen auftritt. Auch auf anderen Umgebungen sowie anderen all-inkl Umgebungen konnten wir das bisher noch nicht nachvollziehen.
Schönen Abend
Sebastian
Möglich, dass ich mich jetzt ganz weit aus dem Fenster lege und völlig falsch liege.
Wenn der OptimizerService per default ausgeführt wird und bei all-inkl. jpegoptim vorhanden ist (wir hatten vor Kurzem ein Serverupdate auf… muss ich morgen in den E-Mails nachgucken), ruft dann das Thumbnailgenerieren für jpg “jpegoptim” auf? Zu “jpegoptim” bin ich in Bezug zu Wordpress darauf gestossen, dass es ggf. auf 0600 setzt und man zusätzlich danach auf 0644 setzen muss. Passen würde es.
Das wäre möglich, ja
Der Fehler könnte aus einem Zusammenspiel von fehlenden Berechtigungen und der Art wie jpegoptim die optimierten Dateien erzeugt zusammen hängen. Standardmäßig scheint jpegoptim die optimierte Version der Datei unter /tmp zu erzeugen, dann das Original zu löschen und die optimierte Version an dessen Stelle zu verschieben. Dabei kann es passieren dass die Berechtigungen nicht mehr so gesetzt werden können wie sie vorher waren. Dazu gibt es auch einen Bugreport: Preserve file permissions · Issue #19 · tjko/jpegoptim · GitHub
Der Workaround scheint zu sein die Originaldatei direkt mit der optimierten Version zu überschreiben, dafür wurde der Parameter -P bei jpegoptim eingeführt den SW aktuell nicht nutzt.
@sonic Könntest Du mal testen ob das Problem noch auftritt wenn Du in der Datei /engine/Shopware/Bundle/MediaBundle/Optimizer/JpegoptimOptimizer.php die Zeile 50 änderst von
return ['--strip-all', '--all-progressive'];
zu
return ['--strip-all', '--all-progressive', '-P'];
Hilft nicht weiter.
Das war gestern Abend auch nur eine schnelle Idee bei der Überlegug, was sich geändert hat.
In der SSH-Console finde ich auch keine binary “jpegoptim” oder “jpegtran”
Falsche Fährte ??? *sorry*
Zumindest in apache-mod kann das auch garnicht funktionieren, wenn die Tools via exec eingebunden werden:
“Bei der Verwendung von PHP als Modul sind die genannten Befehle aus Sicherheitsgründen gesperrt. Um diese Befehle daher in einem Script nutzen zu können, ist die Umstellung auf die CGI Variante von PHP notwendig.”
Wäre super wenn Du den oben genannten Fix in der PHP-Datei trotzdem einmal austesten könntest nur um diese Möglichkeit entdgültig ausschließen zu können.
Ist wohl etwas untergegangen.
Also: der FIX hilft nicht.
Aber: Es scheint dennoch am JpegoptimOptimizer zu liegen.
Änder ich
public function getCommand()
{
return 'DONOTFIND-jpegoptim';
}
um, damit der Opimizer nicht gefunden wird, werden die Thumbnails angezeigt.
Danke für die Klärung und den zusätzlichen Test! Das ist doch schon einmal ein wichtiger Fingerzeig. Ich schau’ mal ob ich noch was finden kann.
Gibt es hier jemanden der das Problem ebenfalls hat und mir temporär SSH und Backend-Zugriff gewähren kann um den Fehler zu untersuchen? Einfach per PM an mich!
Dank der Unterstützung von @webarbeit und @sonic konnte ich einen Quickfix finden:
In der Datei Shopware/Bundle/MediaBundle/OptimizerService.php muß die Zeile 54 angepasst werden. Statt nur
$optimizer->run($filepath);
sollte dort hin:
$perms = fileperms($filepath);
$optimizer->run($filepath);
chmod($filepath, $perms);
Sprich: Bevor wir den Optimizer für eine Datei aufrufen speichern wir uns deren Berechtigungen weg und setzen sie nach der Optimierung noch einmal explizit.
Das Problem bei all-inkl scheint zu sein dass dort zwar jpegoptim installiert ist, allerdings in einer so alten Version dass der --perserve-perms Parameter dort noch nicht existiert.
Viele Grüsse
Hendrik
Funktioniert wieder mit 5.2.18
Hi,
also bei mir funktioniert die Sachen mit dem Update auf 5.2.18 nicht. Die Datei wurde zwar mit den Update geändert, aber ich kann keine Thumbnails generieren…
Hat jemand noch eine andere Lösung?
https://forum.shopware.com/discussion/44479/thumbnails-werden-nicht-erstellt
Wunderschönen guten Tag!
Folgendes Problem ist bei mir eben auch aufgetreten. Nur hat das diesmal nicht mit dem oben gennanten Fix zu tun der ist in 5.2.18 schon drinnen, sondern mit der Variable finfo in der OptimizerService.php
[Tue Feb 28 14:58:06.701399 2017] [:error] [pid 495] [client 213.225.13.212:17559] PHP Fatal error: Uncaught Error: Class 'finfo' not found in /srv/www/htdocs/shopware/engine/Shopware/Bundle/MediaBundle/OptimizerService.php:73\nStack trace:\n#0 /srv/www/htdocs/shopware/engine/Shopware/Bundle/MediaBundle/OptimizerService.php(50): Shopware\\Bundle\\MediaBundle\\OptimizerService->getMimeTypeByFile('media/image/26/...')\n#1 /srv/www/htdocs/shopware/engine/Shopware/Bundle/MediaBundle/CacheOptimizerService.php(56): Shopware\\Bundle\\MediaBundle\\OptimizerService->optimize('media/image/26/...')\n#2 /srv/www/htdocs/shopware/engine/Shopware/Components/Thumbnail/Generator/Basic.php(301): Shopware\\Bundle\\MediaBundle\\CacheOptimizerService->optimize('media/image/26/...')\n#3 /srv/www/htdocs/shopware/engine/Shopware/Components/Thumbnail/Generator/Basic.php(107): Shopware\\Components\\Thumbnail\\Generator\\Basic->optimizeImage('media/image/26/...')\n#4 /srv/www/htdocs/shopware/engine/Shopware/Components/Thumbnail/Manager.php(147): Shopware\\Components\\Thumbnail\\Generator\\Basic->createThumbnail('media/image/MWT...', '/media/image/th...', ' in /srv/www/htdocs/shopware/engine/Shopware/Bundle/MediaBundle/OptimizerService.php on line 73, referer: https://www.miracle-woman.com/backend/
Habt ihr hierfür eine Lösung? Hab schon probiert die Rechte zu ändern um dem Problem entgegen zu wirken. Danach bin ich erst auf diesen Error gestoßen.
EDIT: Ok hab den Fehler gefunden die fileinfo extension war nicht aktiviert. Jetzt meine Frage weshalb der Fehler erst bei 5.2.20 auftritt. Hab von 5.2.16 upgedatet aber hätte nirgendwo die wichtigkeit dieses Moduls herausgelesen. Hoffe das es nun wieder funktioniert die Bilder hochzuladen.
EDIT: Ok hab den Fehler gefunden die fileinfo extension war nicht aktiviert. Jetzt meine Frage weshalb der Fehler erst bei 5.2.20 auftritt. Hab von 5.2.16 upgedatet aber hätte nirgendwo die wichtigkeit dieses Moduls herausgelesen. Hoffe das es nun wieder funktioniert die Bilder hochzuladen.
Hallo zusammen, hatte gleiches Problem unter SW 5.2.20 prof. /PHP7 … auch bei mir fehlte die extension am Server … @Shopware Support: Eigentlich wäre das seitens SW fein, wenn man diese doch nun wichtige extension in die Systemvoraussetzungen übernehmen würde, bzw auch unter Systeminfo wie die anderen extensions die fileinfo auflisten und „grün“ abhaken würde wenn alles ok ist. Wie man sieht läuft das backend ohne der extension nicht wirklich brauchbar fürs Anlegen von Artikel. Nur so ein Vorschlag !!
LG. Klaus
Guten Abend.
Ich habe eben das Update auf 5.3.1 gemacht und wieder sind alle Bilder weg.
Wenn ich mich per FTP aufschalte sind auch die ganzen Ordner leer.
Das kann doch nicht sein?!?!?
Hier zum neuen Post mit Bezug zu Version 5.3 https://forum.shopware.com/discussion/48349/nach-update-auf-5-3-1-alle-bilder-weg