Beiträge von ulli

  • FP 10 - 2 Probleme

    Zitat von ibex81

    Danke Superman ;)



    Vorab: Das "Superman" wird von der Forensoftware vergeben, wahrscheinlich nach Anzahl der Postings. Auf jeden Fall bezieht sich das nicht auf meine Programmierkenntnisse. Die sind eher bescheiden.

    @ibex: jetzt hast Du mich aber verunsichert: Ich habe nachgeschaut, und tatsächlich ist der Google-Analytics-Code nach FP10 aus dem Quelltext verschwunden. Dennoch trackt Analytics meinen Shop weiter, sogar korrekt die Verkäufe usw. Keine Ahnung, wieso!

    Siehst Du: kein "Superman".

  • Namensformat vorhandener Produktbilder umstellen?

    Derzeit habe ich rund 6500 Produktbilder im Shop. Davon sind ca. 5000 im Namensformat product_id.jpg (noch aus dem am Anfang übernommenen xtc-Datenbestand), die restlichen 1500 habe seitdem aus SEO-Gründen konsequent mit product_name.jpg angelegt.

    Nun möchte ich die 5000 Bilder im Bestand auch auf product_name.jpg umstellen. Das würde zwar "einfach" gehen, indem ich bei der derzeitigen Format-Einstellung "p_name.jpg" jedes einzelne der 5000 Bilder unter Produkte -> Bearbeiten erneut uploade und danach das Imageprocessing durchlaufen lasse. Aber praktisch ist das nicht durchführbar.

    Gibt es nicht einen Weg über ein php-Skript o.ä., um die auf dem Webspace im Ordner images/product_images/original_images liegenden Bilder vom alten Namensformat auf die zugehörigen Produktnamen umzubenennen, wie das sonst beim Upload geschieht? Natürlich müssten in diesem Zuge dann automatisch auch die entsprechenden Datenbankeinträge in den Tabellen "products_description" (für das Hauptbild) und "products_images" (für die Zusatzbilder) aktualisiert werden.

    Wie gesagt, von Hand ein nicht zu bewältigendes Unterfangen. Aber vielleicht hat ein php-Profi unter euch, oder auch der admin oder einer von den cseo-Entwicklern eine Ideee?

  • mit FP10 Bestellung per Sofortüberweisung

    Genau. Auch ich habe das mit Hilfe des Supportmitarbeiters von Sofortüberweisung gelöst.

    Denn http-Link habe ich von Hand eingetragen, sollte kein Problem sein. Die Schleife hatte ich auch, ist aber nach automatischer Neuerstellung des Projektes beseitigt.
    SÜ läuft danach wieder ohne Probleme wie vorher. Hatte seitdem schon einige Transaktionen.

  • Problem mit Bid-Dateinamen

    Imageprocessing bearbeitet nur die Bilder, aber nicht die Dateinamen.

    OK - ich habe jetzt alle Bildnamen offline geändert und die Bilder noch einmal neu hochgeladen. Ist jetzt OK.
    In Zukunft werde ich darauf achten, dass meine Bildnamen keine Umlaute enthalten oder diese vor dem Upload ändern auf ae, oe, ue.

  • Problem mit Bid-Dateinamen

    Zitat von jotest

    Mit fp10 geht es wen man Produktbilder über admin upload, kommen den richtig in den products /products_image name mit utf8 ohne umlaut und und.



    Was meinst Du mit "admin upload" ?
    Meinst Du unter "Produkte -> Produkt bearbeiten"? Dort funktioniert es richtig, wie von Dir beschrieben. Aber da muss ich jedes Bild einzeln bei jedem Produkt eintragen.
    Oder gibt es ein Massenupload?

    Ich habe alle Bilder in ein zip-Datei per FTP in den Ordner "original_images" geladen und dann über Imageprocessing die Bilder erstellt.
    In der Datenbank habe ich in der Tabelle product_images die Bilder eingetragen, ebenfalls über Dateiimport. Anders kann ich es bei großen Bildmengen doch nicht machen.

  • mit FP10 Bestellung per Sofortüberweisung

    Hatte ich auch.
    Mit FP10 ist ein neues Modul pn_sofortueberweisung.php eingespielt worden. Daher in der Konfiguration Sofortüberweisung einmal deinstallieren und neu installieren. Am besten per automatischer Einrichtung (neues Projekt).
    Danach sollte alles wieder wie gewohnt laufen.

  • Problem mit Bid-Dateinamen

    Ich habe die Bildernamen auf Produktnamen umgestellt und dabei (dummerweise) einige Dateinamen mit Umlauten. Ist soweit kein Problem, sowohl in der Datenbank (table product_images) als auch auf dem Server bereiten diese keine Probleme.

    Aber die Variablen in der product_info_v1.html erzeugen die die Bilddateinamen nicht UTF8-konform und werden somit zu toten Bildlinks.

    Beispiel:
    href="{$img_path_popup}" gibt als Ergebnis
    href="/images/product_images/info_images/8-030_Umh%C3%A4ngetasche-Crossover.jpg"
    obwohl das Bild "8-030_Umhängetasche-Crossover.jpg" heißt.

    Gibt es eine Möglichkeit, dass die Variable den Namen korrekt in UTF8 ausgibt?

  • Popout Bilder

    Das ist ein alter Fehler in der Konfigurationsdatei, hatte ich schon vor einigen Monaten hier gepostet.
    Ist aber im FP10 noch immer nicht behoben!

    admin: Nimmst Du das mal auf?

    Schnelle Lösung:
    Ich habe das seinerzeit so gelöst, dass ich die Höhe direkt in der DB in der configuration table eingetragen habe. Denn das Feld ist in der Datenbank enthalten. Danach habe ich mich nicht weiter darum gekümmert. Nehme an, dass Du auch nicht jeden Tag die Einstellungen ändern willst, sondern es nur einmalig einstellen willst.

  • FP10 - Cache leeren

    Ich habe jetzt folgende Einstellungen:

    Cache benutzen: false
    Cache Ordner: cache
    Cache Lebenszeit: 5
    Prüfe ob Cache modifiziert: false
    DB Cache: true
    DB Cache Lebenszeit: 3600

    Ist das in Ordnung, oder sollte der DB Cache auch auf false stehen?

  • V2- Modul "Frage zum Produkt"

    Den Email-Betreff wollte ich von "Frage zum Produkt" erweitern zu
    Frage zum Produkt {$product_name} {$products_model}
    um die Anfragen gleich im Mailprogramm zuordnen zu können.

    Leider werden die Variablen nicht angesprochen. Gibts dazu eine Lösung?

  • FP10 - Cache leeren

    Der Cache-leeren-Funktion im Admin löscht zwar die herkömmlichen Dateien, aber nicht die adodb-Ordner:

    /htdocs/shop/cache/f4 konnte nicht gelöscht werden
    /htdocs/shop/cache/64 konnte nicht gelöscht werden
    /htdocs/shop/cache/a6 konnte nicht gelöscht werden
    /htdocs/shop/cache/b9 konnte nicht gelöscht werden
    /htdocs/shop/cache/a5 konnte nicht gelöscht werden
    /htdocs/shop/cache/8e konnte nicht gelöscht werden
    /htdocs/shop/cache/99 konnte nicht gelöscht werden
    /htdocs/shop/cache/51 konnte nicht gelöscht werden
    /htdocs/shop/cache/d0 konnte nicht gelöscht werden
    /htdocs/shop/cache/0d konnte nicht gelöscht werden
    /htdocs/shop/cache/9c konnte nicht gelöscht werden
    /htdocs/shop/cache/45 konnte nicht gelöscht werden
    /htdocs/shop/cache/67 konnte nicht gelöscht werden
    /htdocs/shop/cache/ba konnte nicht gelöscht werden
    /htdocs/shop/cache/0c konnte nicht gelöscht werden
    /htdocs/shop/cache/33 konnte nicht gelöscht werden
    /htdocs/shop/cache/d5 konnte nicht gelöscht werden
    /htdocs/shop/cache/4c konnte nicht gelöscht werden

    Also bleiben diese Cache-Dateien ungeleert?
    Hängt sicher mit dem neuen adodb zusammen. Aber kann das jemand erklären? Was bewirkt adodb, was macht der Cache?

    Welche Einstellungen sind unter "Konfiguration/Cache Einstellungen" richtig bzw. sinnvoll?

  • FP10 - es hagelt Fehler!

    Ist aber keine Lösung.
    Ich habe zum Beispiel den Name des Kunden im Betreff (wegen besseren Suchmöglichkeiten im Email-Programm). Da stört mich das schon lange, dass Herr Schröder im Email-Betreff Schr�der heißt.

    Aber das kriegen die Jungs ín Erfurt auch noch hin, wetten?

  • FP10 - fehlertolerante Suche

    Nach FP10 gibt die fehlertolerante Suche bei Schreibfehlern im Suchbegriff keine Alternativvorschläge mehr aus, sondern lediglich "Artikel wurde nicht gefunden".

    Mit der alten Datei /includes/modules/fuzzy_search.php erfolgt die Ausgabe der Alternativvorschläge noch korrekt.

    Die fuzzy_search.php aus FP10 unterscheidet sich einzig in der Zeile 115:
    $split_content = explode(SEARCH_SPLIT_PRODUCT_CHARS, $word_string);

    Vorher lautete die Zeile:
    $split_content = split(SEARCH_SPLIT_PRODUCT_CHARS, $word_string);

    Warum wurde in dieser Zeile in FP10 "split" gegen "explode" ausgetauscht? Genau das bewirkt offensichtlich, dass keine Alternativvorschläge mehr angezeigt werden! Das ist aber doch gerade der Sinn einer "fehlertoleranten Suche"

    Tritt der Effekt bei euch auch auf?