Hi, bin etwas verwirrt über den richtigen Ort für Artikelbilder. Wenn ich (per COI hochgeladene) Artikelbilder ansehe, dann haben stehen sie
im Admin je nach Bildgröße im Verzeichnis
/out/pictures/generated/product/1/390_245_75/ oder
/out/pictures/generated/product/1/87_87_75/ oder
/out/pictures/generated/product/1/540_340_75/
Im shop hat das Artikelbild die URL
/out/pictures/generated/product/1/540_340_75/
Soweit also so gut. Aber beim Klick auf das Artikelbild im Shop will das Bild in
/out/pictures/master/product/ geöffnet werden. Die Folge: Fehler “Image could not be loaded” und ein htaccess Fehler.
Ich verstehe nicht, weshalb da nicht das Bild in *generated geöffnet werden soll bzw. wie ich den Fehler vermeiden/beheben könnte. Verwendet wird Theme “wave”
und was passiert wenn du ein bild ganz normal backend hochlädst? kommt frontend die gleiche fehler?
hast du irgendwas in .htaccess geändert? wenn ja, stelle mal die original wieder her und schau ob es besser wird.
Master Bild ist das, was man übers Backend hochgeladen hat. Daraus werden mehrere generated Bilder in passenden Größen für die Anzeige im Frontend erstellt.
Mir ist aber schon mal aufgefallen, dass der Shop Master Bilder ausliefert, wenn kein generated Bild erstellt werden konnte.
So wie es klingt, überspringt COI das Master Bild, das ist aber falsch. Prüfe auf jeden Fall die Dateiberechtigungen der Bilderordner, vielleicht fehlen dort die Schreibrechte.
beim klick auf das Artikelbild im shop wird das master-bild geladen, da das ja das größte Bild ist
Danke für Eure Antworten
@OXID-Design: Hochladen über backend (getestet mit 2. Bild) ändert nichts am Problem, lediglich der Pfad die Nummer im Pfad ändert sich von 1 auf 2.
Die Original .htaccess habe ich nicht mehr, aber meine Änderungen beziehen m.E. sich nur auf die Erzwingung von https. Woher könnte ich eine originale .htaccess bekommen?
@vanilla_thunder: Die Berechtigung für …master… und für …generated… sind identisch.
Nun wollte ich bem Demoshop mal nachsehen, aber dort ist es ein anderes Theme und die “Innereien” sehe ich dort eh nicht.
COI überspringt m.E. das Master nicht, denn erstens ist dieses im richtigen Pfad vorhanden und zweitens auch richtig beim Artikel, Reiter Bilder, eingetragen. Auch Thumbnail und Icon werden korrekt generiert. Gibt es vielleicht einen Ansatz zur Fehlersuche in der Datenbank? Denn das Master-Bild ist zwar vorhanden, aber genau genommen kommt beim Klick auf das Artikelbild zuerst ein dunkles halbdurchsichtiges ganzseitiges “Bild” mit einem Linktext “The image could not be loaded” und Navigationspfeilen, falls mhrere Artikelbilder vorhanden sind und erst beim Klick auf den Link kommt der Fehler “Forbidden You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe.” Was ja vielleicht gar nicht völlig falsch ist, weil dann der direkte Aufruf des Bildes unterbunden wird und es eigentlich nur über eine (?) Shop-Galerie(?)-Funktion ausgeliefert werden sollte.
@patchwork.de Genau das Master-Bild laden funktioniert bei mir nicht. Habe auch getetestet, ob das Master-Bild zu groß sein könnte, Verhalten ist aber auch bei kleinem Bild identisch.
Gibt es eine Möglichkeit, durch .htaccess verursachte Fehler zu debuggen? Wie sonst könnte ich den Fehler eingrenzen?
kannst du den einen generated bild im backend als vorschau öffnen?
htaccess auf github evtl.
Ja, problemlos, aber da werden ja auch die Bilder in generated genutzt. z.B.:
/out/pictures/generated/product/1/540_340_75/img…jpg
was passiert wenn du flow aktivierst?
ja, ich sehe schon, es funktioniert trotzdem nicht.
hast du productmain.tpl bearbeitet bzw. ist irgendein modul aktiv die zoom bilder beeinflussen könnte? deaktiviere die mal.
wie ich sehe, funktioniert der shop und generated bilder werden ja grundsätzlich geladen, nur der größere zoom bild nicht.
kannst du den einen zoom bild aus dem master ordner im browser öfnnen?
Stimmt, flow ändert nichts.
productmain.tpl ist unbearbeitet
keine module, die bilder beeinflussen könnten, allenfalls “WYSIWYG Editor + Mediathek”
nein, das ist so, wie wenn ich auf den in vorherigem Beitrag genannten Link “the image could not be loaded” klicke.
Habe nun mal debuglevel 4 eingestellt gehabt. Auf der Artikel-
Detailseite erscheint ein Warning. Keine Ahnung, ob das überhaupt was mit meinem Problem zu tun hat???
Warning: {oxscript} resource not found: js/widgets/oxflyoutbox.js in /www/htdocs/x08154711/shop.xyz.com/vendor/oxid-esales/oxideshop-ce/source/Core/ViewHelper/JavaScriptRegistrator.php on line 83
Was dort steht, verstehe ich aber nicht:
Z81 if (empty($url) && $config->getConfigParam(‘iDebug’) != 0) {
Z82 $error = "{oxscript} resource not found: " . getStr()->htmlspecialchars($file);
Z83 trigger_error($error, E_USER_WARNING);
Z84 }
ja, aber schalte doch eine theme ein die unbearbeitet und original ist. ich sehe zbsp. das dein flow, vor allem varianten modifiziert wurde. azure geht auch.
ich hatte mal ein ähnliches Problem, das mit der Konfiguration der PHP-Interpreter auf dem Server zusammen hing.
Das Ende der Geschichte war, dass das Recht zum Ausführen (Abgekürzt mit “X”) für irgendeinen Ordner gefehlt hat.
So sehen die Berechtigungen von meinem out Ordner aus:
Schau mal, ob dein
master Ordner + alle Unterordner ebenfalls 775 haben.
Und die Fehlermeldung von eben heißt nur, dass der Shop die Datei js/widgets/oxflyoutbox.js nicht findet. In wave gibts das nicht, hast du vielleicht Code für ein anderes Theme in dein Child Theme copy-pasted?
Aber mit dem Bilder-Problem hat es nichts zu tun.
Jetzt habe ich doch noch was gefunden: In …master… haben die Bilder die Dateirechte 0644, in …generated… haben sie 0755.
Nur WARUM ist das bei den Bildern jeweils anders?
Die Ordner haben alle 0755
Und noch was:
Der Link beim Artikelbild lautet:
https://shop.xyz.com/out/pictures/master/product/3/img.jpg
Der reale Pfad zum Bild:
https://shop.xyz.com/source/out/pictures/master/product/3/img.jpg
Sprich dem Link “fehlt” das “source/” für einen direkten Aufruf im Browser.
[ Einschub: Nur solange etwas durch shop-Funktionen ausgeführt wird, kann das source/ entfallen, da es über den Wert für sShopDir in der config.inc.php mit eingeschlossen wird ($this->sShopDir = ‘/www/htdocs/x08154711/shop.xyz.com/source’
- So mein laienhaftes Verständis]
Bin gerade stuck, am WE geht’s weiter. Vielleicht hat ja noch jemand eine Idee oder kann das mit seinem Shop vergleichen…? Danke soweit mal.
nein, mir source/ in der URL hat es nichts zu tun.
Eineseits läuft dein Shop auf shop.xyz.com und nicht auf shop.xyz.com/source
und anderersetis haben die URLs der generated Bilder auch kein source.
An 644 dürfte es auch nicht liegen, aber du könntest es mal probeweise auf 755 ändern.
Das war leider eine Falschaussage. Habe nochmal geprüft (Danke an @patchwork.de ) und die numerierten Unterordner von …/mster/product/… also 1, 2, usw. hatten 0744. Wenn ich das auf 0755 ändere, kann ich die Originalbilder in Master aufrufen und Zoom zeigt sie auch an.
Habe nun probehalber im Admin bei einem Artikel ein 4. Bild hochgeladen und der neu erstellte Unterordner 4 hat nun wieder die Rechte 0744. Also gleiches Spiel von vorn.
An welcher Stelle wird definiert, welche Rechte ein neuer Ordner haben soll?
hier spielt eher der server eine rolle, oxid macht da nichts.
Versuch mal hier und in der Zeile 385 (in der v6.1 könnten andere Zeilen sein, aber es geht um die beiden Funktionen _copyFile und _moveFIle) den Wert 0744 durch 0755 zu ersetzen:
Ein herzliches Dankeschön an alle, die mitversucht haben, das Problem zu lösen! @OXID-Design @patchwork.de und @vanilla_thunder. Übrigens: Die Zeilennummern haben sich nicht geändert.
Jetzt ist mir aber nicht klar, weshalb scheint das nur bei mir ein Problem zu sein? Woher stammen die Werte in “shop.xyz.com\vendor\oxid-esales\oxideshop-ce\source\Core\UtilsFile.php” und überstehen sie den nächsten Update? Wäre da ein Bugfix angebracht?
Das ist im Endeffekt eine Frage der Serverkonfiguration und bei den meisten scheint es ja irgendwie zu laufen. Dennoch empfinde ich die 744 Berechtigung auf Ordnern eher als unüblich.
Könntest du vielleicht sagen, um welchen Hoster und welches Hosting-Paket es sich da handelt?
Nach dem Update dürfte das Problem aber nicht wieder aufkommen, da die Ordner nur dann durch OXID erstellt werden, wenn sie gänzlich fehlen. D.h. du müsstest jetzt mal alle Ordner erstellen und die Berechtigungen richtig setzen, dann grätscht OXID da auch nicht mehr dazwischen.
sobald er bildqualität aktuell von 75 auf xy ändert, hat er wieder das gleiche problem. aber du hast recht, 744 ist ungewöhnlich. ich weiß nur, das bestimmte hoster auf 777 allergisch reagieren und dann die zugang verweigern.
All-inkl.com mit ALL-INKL Premium