Bilder fehlen nach Update auf 6.4.2

Deutsches Forum
1

Hallo zusammen,

ich habe innerhalb einer VM den Shop von 6.1.5 schrittweise auf die 6.4.2 aktualisiert.
Das lief im Allgemeinen auch ganz gut. Jedoch werden keine Artikelbilder mehr angezeigt.
Die Bilder sind noch in den jeweiligen Ordnern jedoch wird im Frontend ewig geladen (es wird nur der “spinner” angezeigt) und in der Einzelansicht ist der SRC vom IMG tag leer.
Beim Artikel kann ich kann ich sehen, dass ein Bild zugeordnet ist. Die Vorschau läd das Backend einfach neu.
Ich bin ziemlich ratlos und hoffe jemand hat eine Idee.

2

Ist das bei URL - Aufruf mit www oder ohne www ?

3

Der Test-Shop läuft in einer VM und ohne www.
Der Live-Shop läuft mit einer Subdomain.

Theoretisch sollte alles am richtigen Ort sein und vom Server auch beschreibbar sein.

4

Ich vermute, das es daran liegt. Bei mir was es von der Schilderung her genauso.

Der Spinner dreht sich, aber es werden keine Artikelbilder geladen.

Im LIVE - hat es mit xyz.de nicht funktioniert. Beim Aufruf www.xyz.de aber schon.

Ich habe es dann so gelöst, dass ich in der .htaccess einen Redirect eingerichtet habe.

5

Nope. Gute Idee, leider ohne Erfolg.

Zur sicherheit habe ich auch die Site-config im Apache angepasst und neugeladen.
Keine Änderung ob mit oder ohne-www.

6

Browser-Cache geleert, OXID-TMP geleert, Views aktualisiert?

7

Prüfe mal bitte in Deinem Quellcode, ob überhaupt die URL der jeweiligen Produktbilder drin steht.

8

@rubbercut : Jap. Alles geleert.
rm -rf source/tmp/* und vendor/bin/oe-eshop-db_views_generate laufen gelassen

@dentakon : Im ersten Post hatte ich ja geschrieben, das <img src=""> leer ist.
In der Übersicht bleibt der Spinner. Einzelansicht zeigt das Alt tag an.

Grundsätzlich scheint die Verbindung schon da zu sein und er kann nur die Bilder nicht laden.
Die Ordner gehören der www-data Gruppe an und haben alle chmod 775 gesetzt.

Habe ich etwas übersehen?

9

Probiere mal, ob es was mit http bzw. https zu tun hat.

Ich bin mir sicher, dass es an der .htaccess und deren config liegt.

10

Ok. Momentan läuft das unter der Domain oxid.localhost, da ich https nicht eingeplant hatte.
Ich habe gerade die .htaccess umbenannt, alle caches gelöscht, und erneut versucht. Keine Änderung.
Bilder sind alle im master und generated vorhanden.

Ich habe jetzt kurz ein self-signed Zertifikat erstellt und default-ssl.conf aktiviert.
Habe dann die URLs in der config.inc.php angepasst, tmp/* geleert und views neu erstellt.

Jetzt schlägt es auch mit https daneben.

11

Hast du schon nach passenden Einträgen im Shop, PHP oder Apache Log geschaut?

12

@naledre OXID.log zeiggt nur meldungen von heute morgen an:

[09 Sep 08:37:27.216285 2022] [uncaught error] [type E_ERROR] 
[file /var/www/bfw.localhost/source/bootstrap.php] [line 172] [code ] 
[message Uncaught Error: Class 'OxidEsales\Eshop\Core\ConfigFile' not found in /var/www/bfw.localhost/source/bootstrap.php:172

Im Apache steht auch das gegenstück dazu.
Der letzte Eintrag stammt von 14:26 wo ich das SSL Zertifikat erstellt habe.
Also scheint der Fehler von 08:37 nach dem letzten composer update auch behoben zu sein.
Da im IMG tag keine SRC angegeben ist, gibt es auch ind er Browserconsole keine Meldungen…

Mit gehen da solangsam die Ideen aus.

Update nochmal neu starten?
Bin schon beim 2ten Versuch.

13

Sind die Pfade in der config.inc.php

$this->sShopURL = “http…”

alle richtig gesetzt.

Wenn ich dort von https auf http umstelle, habe ich das gleiche Fehlerbild.

14

Ok, Ratestunde:
skipviews aktiv?

15

Auch ein guter Ansatz.
Hatte alle bis auf die erste URL auf https gesetzt.
Habe jetzt gerade alles auf https geändert, TMP geleert, Views neu erstellt, Hard reload im Browser…
Und keine Änderung.

SkipViews ist nicht aktiv. Es funktioniert alles soweit. Backend etc… alles gut. Fonts werden geladen, Grafiken auch. Cookiebot meckert, weil die domain nicht freigegeben ist.
Ich habe in der Grundkonfiguration den Produktivmodus deaktviert (in der hoffnung auf mehr infos)
In der config.inc.php ist iDebug auf 3 gestellt.

Keine Fehlermeldungen, keine Infos,…
…als wenn alles laufen würde.

16

Hi,
Was steht in der oxarticles in deinem oxpicx und sind deine Rechte für die Ordner korrekt gesetzt inkl. Besitzer und Gruppen?

Nur so ein Denkanstoß.
LG Brian Brian

17

Noch ne Idee:
Wenn deine Bilder in Master sind, setze mal in deiner oxarticles in der Spalte oxgenerated alles auf 0 dann alles leeren tmp etc. Und Frontend neuladen…
Alternativ reicht es auch die Qualität der Bilder im backend zu ändern, dann würde OXID neue unterordner anlegen zb xxxxx_90 wenn 90 der Qualitätswert ist.

Ich tippe aber eher auf Rechte in den Ordnern.

18

Das ist veraltet (oxpicsgenerated). Einfach den Ordner generated löschen oder umbenennen.

1 Like
19

Das Lasy Loading in den Standard Themes bei OXID eSales erfolgt über jQuery Plugin unveil() jQuery Unveil - A very lightweight plugin to lazy load images bzw. https://github.com/luis-almeida/unveil/blob/master/jquery.unveil.js

Im Flow Theme Version 3.8.0 (für CE 6.4.2) liegt dies im Build Vendor Verzeichnis https://github.com/OXID-eSales/flow_theme/tree/v3.8.0/build/vendor/jquery-unveil/js und verwendet wird es im main.js Datei https://github.com/OXID-eSales/flow_theme/blob/v3.8.0/build/js/main.js was später nach Generierung in scripts.min.js liegt wichtig ist dabei der Aufruf

$("img").unveil();

Dieser Aufruf muss gesetzt sein, damit überhaupt die Bilder nachgeladen werden:

<img src="[{$oViewConf->getImageUrl('spinner.gif')}]" data-src="[{$product->getThumbnailUrl()}]"...

Quelle: https://github.com/OXID-eSales/flow_theme/blob/v3.8.0/tpl/widget/product/listitem_line.tpl#L67

Beim Nachladen wird der Wert aus src durch den Wert aus data-src ersetzt. Wichtig dabei ist auch, dass es kein Misch-Masch von den hinterlegten Bild URLs gibt zwischen http und https.

Tipp wäre einfach mal in der Browser-Konsole nach JavaScript Fehlern Ausschau zu halten.

1 Like
20

Hi rubber, war ja nur eine von beiden Ideen ,-)