Marktplatz - Eine große Auswahl an neuen und hilfreichen Modulen sowie modernen Templates für die modified eCommerce Shopsoftware
Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: Probleme nach Update von xt:Commerce auf modified eCommerce Shopsoftware

    bolero

    • Neu im Forum
    • Beiträge: 49
    Hallo,

    ich habe gerade ein Update von xt:Commerce 3.0.4 SP2 auf modified eCommerce Shopsoftware 1.05 SP1a durchgeführt (gemäß: Tutorial: Datenbestand eines xt:Commerce Shops in die modified eCommerce Shopsoftware übernehmen). Lief soweit problemlos durch, aber es gibt leider zwei gravierende Probleme.

    1. die meisten oder vermutlich alle Produktbilder sind weg.
    Alle Bilder von Kategorien sind ebenfalls weg bis auf exakt eines. Bei einem Vergleich dieses Bildes mit den anderen habe ich festgestellt, daß dieses 644 ist, während alle anderen Kategorie-Bilder 777 waren. Ich habe daraufhin die Rechte angepaßt und die kompilierten Templates gelöscht, das hat nichts geändert. Und die Thumbnails liegen sowieso alle in 644 vor. Es muß also ein hochgradiger Zufall gewesen sein, daß ausgerechnet dieses eine Bild abwich. Bei den nicht angezeigten Bildern wird überall "noimage.gif" angezeigt. Mir ist nicht klar, ob das angezeigt werden sollte, falls kein Bild im Datensatz eingetragen ist oder ob eine Prüfung auf vorhandene Bilder im Dateisystem stattfindet. Jedenfalls sind bei den Datensätzen überall passende Bildnamen hinterlegt. Irgendwelche Rechteprobleme möchte ich eigentlich komplett ausschließen, da ja ein Bild angezeigt wird und die der anderen Bilder (jedenfalls bei den Kategorien) nun exakt identisch sind. Es gibt keinerlei Fehlermeldungen in irgendeinem Log dazu, so daß die Problemursache so nicht zu finden ist. Bei den Einträgen in der Datenbank zu diesen Kategorien ist auch nichts besonderes zu erkennen.

    2. die Datei "_product_listing_v1.html" aus dem Template wird nicht gefunden:

    Code: PHP  [Auswählen]
    Smarty error: unable to read resource: "xtc5/module/product_listing/_product_listing_v1.html" in /pfadzumweb/shop/includes/classes/Smarty_2.6.26/Smarty.class.php on line 1097

    Dabei macht mich der Anfang mit "xtc5/" etwas stutzig. Ich nehme an, daß hier von einem falschen Verzeichnis ausgehend gesucht wird. Irgendwo muß also ein falscher Pfad zusammengesetzt werden bzw. es fehlt der richtige Anfang des Pfades.

    Vielen Dank für sachdienliche Hinweise. :-)

    Nachtrag:
    1. Ich habe noch zwei weitere Kategorien-Bilder gefunden, die angezeigt werden. Es handelt sich immer um die Bilder, die oben in der Kategorie angezeigt werden. Darunter befindet sich "weitere Unterkategorien", die dann alle mit "noimage.gif" daherkommen, obwohl ein Bild im Datensatz hinterlegt und auch im Verzeichnis vorhanden ist.

    2. das Problem mit dem product_listing taucht immer bei Unterkategorien auf. Hat eine Kategorie keine Unterkategorien, werden die Produkte problemlos aufgelistet (wenn auch ohne Bilder).

    3. Gibt es für ein Produkt mehrere Bilder (nnn_1.jpg, nnn_2.jpg ...), dann werden diese angezeigt. nnn_0.jpg wird hingegen nicht angezeigt, obwohl vorhanden. Im Popup wird auch korrekt durchgezählt, in diesem Fall also 3 Bilder. Aber Bild 1 ist eben noimage.gif

    Linkback: https://www.modified-shop.org/forum/index.php?topic=16246.0

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.369
    • Geschlecht:
    Zu 1.) Hier würde ein Link zum Shop sicherlich helfen.
    Zu 2.) Die Template Datei "_product_listing_v1.html" gibt es in einem Standard-Template überhaupt nicht! Also entweder kopierst du deine "product_listing_v1.html" und benennst die Kopie um in "_product_listing_v1.html" oder du korrigierst das "listing_template" in der Datenbank mit folgendem Befehl:

    Code: SQL  [Auswählen]
    UPDATE categories SET listing_template = 'product_listing_v1.html' WHERE listing_template = '_product_listing_v1.html';

    Grüße

    Torsten

    bolero

    • Neu im Forum
    • Beiträge: 49
    Hallo, danke erstmal! Es handelt sich um den Shop eines Kunden, ich muß erstmal nachfragen, ob es ihm recht ist, daß ich die URL hier veröffentliche.
    Was das Template betrifft: danke für den Hinweis. Ja, da habe ich das "_" beim Vergleichen übersehen. Im Original-xtc4-Verzeichnis liegen da sowohl eine Datei mit und eine ohne Underscore. Da ist "PRODUCTS_SHIPPING_NAME" durch "SHIPPING_NAME" ersetzt worden. Ich vermute, daß das mal ein Bugfix gewesen sein muß. Das habe ich mit deinem SQL-Statement korrigiert.
    Ich hatte zwischenzeitlich einen Nachtrag angefügt, den du evtl. nicht bemerkt hast. Hilft das evtl. weiter in Bezug auf Problem 1.? (Ansonsten muß ich wie gesagt erstmal beim Kunden nachfragen, sicherheitshalber.)

    OK, hier ist eine Beispiel-URL: http://www.strick-stick.de/shop/index.php?cPath=1_54
    Die Unterkategorien dort sollten Bilder haben und auch die Produkte. Bei den Produkten dort kann man auch sehen, daß wie beschrieben die nnn_1.jpg usw. angezeigt werden.

    bolero

    • Neu im Forum
    • Beiträge: 49
    Kleine Unstimmigkeiten, die mir ansonsten aufgefallen sind:
    1. in der Updateanleitung wird auch angegeben, daß man in "configure.org.php" Pfade und Daten anpassen soll. M.E. ist es völlig egal, was da drin steht, sobald ein System erstmal installiert ist, oder nicht?
    2. eine Sache, die mir bei jedem Punkt-Update auffällt: die Prüfung, ob die "configure"-Dateien vernünftige Rechte haben, scheint nur auf 444 zu prüfen. Wenn z.B. "configure.org.php" nur 400 hat, wird ebenfalls eine Warnung im Adminbereich angezeigt.

    bolero

    • Neu im Forum
    • Beiträge: 49
    Habe das Problem mit den Bildern inzwischen lösen können. Es tritt auf, wenn das Web im "safe_mode" läuft und das Verzeichnis "/images/" und dessen Unterverzeichnisse nicht denselben User wie die PHP-Seiten haben (waren beim Anpassen der Rechte auf denselben User gestellt worden, den auch die Bilder aufgrund des Uploads per Apache haben). Leider wird der PHP-Fehler, der sonst aufgeworfen würde, komplett abgefangen. Irgendwo im Code wird da geprüft, ob die Datei vorhanden ist. Der Code kann nicht in das Verzeichnis wechseln und zieht "noimage.gif". Anscheinend gibt es aber auch Codestellen ohne diese Prüfung (bei der "Oberkategorie" selbst und für die zusätzlichen Bilder), da wird die Datei dann problemlos angezeigt, obwohl dieselbe Diskrepanz besteht.

    Ich habe meine Zweifel, ob diese Prüfung überhaupt sinnvoll ist. Ist ein zusätzlicher Zugriff ins Filesystem (die bekanntermaßen langsam sind) für jede einzelne Bilddatei, der fast immer positiv ausfallen wird und dann überflüssig ist. Und wenn er negativ ausfällt, kaschiert er das eigentliche Problem. Oder mißverstehe ich den Sinn der Prüfung?

    web28

    • modified Team
    • Beiträge: 9.404
    [...]
    2. eine Sache, die mir bei jedem Punkt-Update auffällt: die Prüfung, ob die "configure"-Dateien vernünftige Rechte haben, scheint nur auf 444 zu prüfen. Wenn z.B. "configure.org.php" nur 400 hat, wird ebenfalls eine Warnung im Adminbereich angezeigt.

    Das ist beim SP1 Paket behoben.

    [...]
    Ich habe meine Zweifel, ob diese Prüfung überhaupt sinnvoll ist. Ist ein zusätzlicher Zugriff ins Filesystem (die bekanntermaßen langsam sind) für jede einzelne Bilddatei, der fast immer positiv ausfallen wird und dann überflüssig ist. Und wenn er negativ ausfällt, kaschiert er das eigentliche Problem. Oder mißverstehe ich den Sinn der Prüfung?

    Die Prüfung ist sinnvoll, wenn Bilder fehlen (falscher Eintrag in Datenbank) wird der Shop wirklich langsam.
    Deshalb die Ersetzung mit "noimage.gif". Bei der Ersetzung mit "noimage" sieht man sofort, dass der Datenbankeintrag nicht stimmt oder das Bild sich nicht im Verzeichnis befindet.

    Richtige Einstellung für modified eCommerce Shopsoftware: safe_mode: off

    Gruss Web28

    bolero

    • Neu im Forum
    • Beiträge: 49
    Stimmt, ist in der Version SP1a nicht mehr vorhanden. Super. Da ich immer erst 1.05 ohne SPs installiere und dann das integrierte SP1+a drüberhaue, nachdem alles geht, fiel mir das noch nicht auf, da ich nach dem Auftreten der Warnung dann 444 einstelle, damit sie weggeht.

    Zum "safe_mode": nichts für ungut, aber m.E. ist "safe_mode" mit "open_basedir restriction" die einzig richtige Einstellung für jegliches PHP-Programm. Mit etwas gutem Willen läßt sich jedes Programm darunter gut betreiben. Auch modified eCommerce Shopsoftware.