hat jemand schonmal das Problem gehabt, daß zu Produkten in den Listenansichten die falschen Bilder gerendert wurden?
Ich habe das Problem immer mal wieder bei Ca 5% der Artikel. Inhalt des Bildes ist dann der eines völlig anderen Artikels. Dies betrifft nur die Bilder der Infolist/Infogrid/Grid-Seiten! Die Detailbilder sind korrekt…
das schon, aber das thumbnail/icon wird aus dem 1 masterbild generiert. interessant wäre es zu sehen, ob du nicht vlt ausversehen ein anderes bild in der tabelle oxarticles im feld “oxthumb” angibst …möglich wäre auch, das im moment des generierens noch ein falsches bild drin war (oder nicht vorhanden) und das bild quasi erst später kam. ich lade bei meinem shop immer zuerst die bilder hoch, schreibe dann die daten in die DB und hab keinerlei probleme.
auch zeigt dir ja die tatsache, dass nur 5% der bilder betroffen sind schon, dass es kein genereller fehler sein kann sondern irgendwas in deinem ablauf nicht passt.
schau dir doch mal den import genau an. vor allem die betroffenen artikel. was schreibst du da rein? passen die bildnamen? haben die bildnamen vlt komische zeichen? ist es reproduzierbar (sind immer die gleichen artikel betroffen), was passiert wenn du erst bilder hochlädst DANN die artikel.
im notfall kannst du auch einfach oxthumb leeren. dann wird das thumbnail neu generiert. wäre also als workaround möglich… quasi ein 2. import der von allen artikel das thumb/icon löscht und bilder neu generieren lässt.
Tatsächlich ist es so, daß ich ausschließlich das MASTER-Bild hochlade und in die DB schreibe (in der Reihenfolge). Ich gehe/ging davon aus, daß OXID bei der ersten Ansicht des Artikels in einer Liste die OXTHUMB- und OXICON-Einträge brav selber schreibt. Aber wie ich gerade sehe/lerne, tut es das nicht. Die Felder bleiben leer. ABER: Die Bilder werden dennoch berechnet und im entsprechenden Ordner abgelegt, nur manchmal leider mit dem falschen Inhalt.
Vorkommen tut dies meist bei dem 1., 2., 4. und 5., 7., 8. Bild im GridInfo-View (bei 8 Bildern, z.B. Startseite).
Ich möchte jetzt nicht unser Update-Skript weiter aufblasen indem ich es noch die Generierung der verschiedenen kleineren Auflösungen während des Exportes übernehmen lasse. Es braucht - ob der Komplexität der Aufgaben - eh schon ganz schön lange.
Und nur den Dateinamen des Bildes in die DB zu schreiben ohne das dieses vorhanden wäre macht imho auch keinen Sinn.
Vielleicht habe ich auch die Funktion der Spalten OXTHUMB, OXICON, OXPIC1 und vor Allem OXPICSGENERATED wohl nicht richtig verstanden?!
Ich skizziere mal kurz, wie ich es verstanden habe: lade Datei in MASTER-Ordner
schreibe Dateinamen in OXPIC1
setze OXPICSGENERATED = 0 (macht bei mir komischerweise ne 127 rein…)
überlasse OXID OXTHUMB und OXICON einzutragen
naja ich mach nichts anderes in meiner warenwirtschaft (selbst programmiert) …
master bilder hochladen, namen des jeweiligen bildes in die DB schreiben (oxpic1, oxpic2, etc) ich schreibe bei oxthumb (um es zu leeren) extra nen leeren string rein.
dann oxpicsgenerated auf 0 und es funktioniert einwandfrei …
allerdings schreibe ich direkt in die DB und nicht via import.
importierst du über oxid admin oder direkt in der sql via phpmyadmin?
Nun, ich habe ein php-Script was direkt in die DB schreibt - also wie bei Dir. Ggf. sollte ich auch einen leeren String in OXTHUMB schreiben…
Ich denke ja vielmehr, daß der Webserver sich beim Bildergenerieren verhaspelt. Ich denke (weiß es aber nicht), daß OXID nicht Bild für Bild sondern wegen der Geschwindigkeit mehrere Bilder parallel in Thumb und Icon rendert. Anscheinend kommt damit der Webserver nicht klar…
Oder es ist das wirre OXPICSGENERATED = 127 was bei mir komischerweise in die DB geschrieben wird…
vlt ist es auch einfach die extreme menge … probier doch mal schrittweise!
meinst du mit 127 die zahl oder einen NULL wert? aber eigentlich dürfte es daran nicht liegen … weil entweder macht er die bilder neu … oder eben nicht … welches bild er nimmt sollte nicht von einem wert in oxpicsgenerated abhängen!