Beiträge von windmeup

    Nochmal eine grundsätzliche Anmerkung zu den Bildern.
    Die Original-Bilder sollten möglichst groß sein. Bei den Artikeln haben wir uns zu auf eine Bildgröße von 800x630 festgelegt, Format JPG ohne Verluste.
    Daraus werden dann die verkleinerten Bildversionen generiert.
    Wie ich auf Eurem Shop sehen kann, sind schon die Original-Bilder wohl sehr klein, daher extrem pixelig in der Overlay Ansicht. Somit werden durch das Processing die Bilder eher vergrößert als verkleinert, was dann in Folge zu einer deutlichen Qualitätsverschlechterung führt.
    So long und gutes Gelingen.
    Mit Gruß aus dem Sauerland...

    Wenn Du die Bildgrößen unter Bild Optionen verändert hast, mußt Du anschließend noch die Bilder neu berechnen lassen.
    Dies wird unter "Module::cSEO Module::XT-Imageprocessing" (für Produkte/Artikel) erledigt.
    Die Original-Bilder liegen in den Verzeichnissen:
    1. Kategorie: images/categories_orig
    2. Produkte: images/product_images/original_images

    Die anderen Bildgrößen werden dann nach dem Processing in den jeweiligen Verzeichnissen neu angelegt.

    Ich möchte an dieser Stelle das Thema nochmals aufgreifen, da zum Teil mein Problem mit der o.a. genannten Beschreibung zu tun hat.
    Normalerweise werden alle Images zu Kategorien, Produkten und Artikeln per Import-Skript in der Datenbank angelegt, die Bilder-Dateien per FTP in die jeweiligen Verzeichnisse kopiert.
    Allerdings kommt es vor, dass einmal schnell diese importierten Daten geändert werden müssen, also andere Bilder über die Admin-Verwaltung eingefügt werden müssen. Und hier liegt das Problem:
    1. In der SEO Config wurde als Namensformat für Kategorien c_image und für Produkte p_image ausgewählt (also Bildernamen beibehalten)
    2. Die Bildnamen enthalten Unterstriche im Filenamen (z.B. Kategoriebild_254x164_Artikel_01.jpg). Diese Unterstriche gehen nach dem Speichern verloren.
    Anpassung der preg_replace Funktion in inc/cseo_get_url_friendly_text.inc.php (ca. in Zeile 18):

    Code
    alt:$validUrl = preg_replace("/[^a-z0-9-]/i","", $validUrl);
    Code
    neu:$validUrl = preg_replace("/[^a-z0-9-_]/i","", $validUrl); // der Unterstrich nach 9- ist es

    3. Die Bilder werden zwar im upload hochgeladen aber 3 Zeilen weiter wieder gelöscht. Der Eintrag mit dem jetzt richtigen Filenamen steht zwar in der Datenbank , aber das File ist weg.
    Hierzu folgende Anpassungen in admin/includes/classes/categories.php (ca. Zeile 190, ca. Zeile 568)

    Code
    alt:@unlink(DIR_FS_CATALOG_IMAGES.'categories_org/'.$categories_image_name);
    Code
    ändern in:if(IMAGE_NAME_CATEGORIE == 'c_id' || IMAGE_NAME_CATEGORIE == 'c_name')    @unlink(DIR_FS_CATALOG_IMAGES.'categories_org/'.$categories_image_name); // File nicht löschen wenn c_image


    Für die weiteren Produktbilder:

    Code
    alt:$products_image_name = $new_products_name.'-'.($img +1).'.'.strtolower($nsuffix);
    Code
    ändern in:if(IMAGE_NAME_PRODUCT == 'p_id' || IMAGE_NAME_PRODUCT == 'p_name')    $products_image_name = $new_products_name.'-'.($img +1).'.'.strtolower($nsuffix);else    $products_image_name = $new_products_name.'.'.strtolower($nsuffix); // Filename beibehalten, ist eindeutig, also kein Zähler anhängen


    Ein Paar Zeilen weiter unten dann:

    Code
    alt:@xtc_del_image_file($products_image_name);
    Code
    ändern in:
    if(IMAGE_NAME_PRODUCT == 'p_id' || IMAGE_NAME_PRODUCT == 'p_name')
        @xtc_del_image_file($products_image_name);     // lösche das File nicht bei p_image

    Jetzt bleiben die Files erhalten, die Filenamen werden nicht geändert und die weitere Verarbeitung des Imageprocessing funktioniert ebenfalls.

    Das sind Daten die bei der ersten Installation (also mit dem ersten Benutzer = Admin) angelegt werden. Dieser User hat in aller Regel die ID 1.
    Während der Installation mußt du auch eine Adresse, email, etc. anlegen. Diese findest du in der DB-Tabelle address_book wieder.
    Du mußt also die Stammdaten des Admin editieren, oder eben direkt in der address_book z.B. per phpMyAdmin.
    Das Impressum in den emails ist ein Mix aus Konfiguration (Shop-Name, Shop-Besitzer) und den Daten aus der Adresse des Admin.
    Als Ergänzung mal unsere Signatur (Impressum) der Text-Email mit Kommentaren:


    Definiert wird das Ganze in dem Script: inc/cseo_get_mail_body.inc.php

    Kann ja sein das das gewollt ist, aber ....

    Alle strpos($PHP_SELF, FILENAME_.....) in den if-Anweisungen funktionieren so nicht, denn in PHP5 wird auch ein return-Wert mit "0" als false zurückgegeben. Somit werden alle Anweisungen innerhalb der if-Schleifen nicht ausgeführt, obwohl die Bedingung eigendlich wahr ist.

    Die if-Anweisungen müßten also geändert werden (hier als Beispiel die erste if):

    Code
    if(strpos($PHP_SELF, FILENAME_CHECKOUT_PAYMENT) === 0)    echo $payment_modules->javascript_validation();

    Die nächste if-Schleife beginnt dann mit:

    Code
    if(strpos($PHP_SELF, FILENAME_CREATE_ACCOUNT) === 0 ||
    strpos($PHP_SELF, FILENAME_CREATE_GUEST_ACCOUNT) === 0 ||
    strpos($PHP_SELF, FILENAME_ACCOUNT_PASSWORD) === 0 ||
    .....
    usw.


    Wichtig hierbei der Vergleichsoperator (3 Zeichen).
    Siehe auch den Hinweis auf: http://de.php.net/manual/de/function.strpos.php

    Achso eins noch:
    Im Falle der Konto-Erstellung (create_account.php) stimmt dann auch die FORM_ACTION nicht.
    Hier muß der "onsubmit" heißen:
    onsubmit="return check_form(this);"
    Sonst gibt es einen javascript-Fehler (create_account nicht deklariert).

    Hallo ginabella,
    Der user der bei der ersten Installation angelegt wurde erhält die ID = 1
    Dieser User ist angelegt in den DB-Tabellen:
    customers --> customers_id = 1 , Anmelde-email-Adresse und Passwort
    address_book --> address_book_id = 1 , alle weiteren Informationen

    Bitte diese IDs (ich meine die o.a. Felder) niemals ändern, hängt alles möglich von ab.

    Aufgefallen ist das Problem, da ich für unseren Shop einen automatischen email-Versand eingebaut habe.
    Diese Automatik prüft das Vorhandensein von Rechnungen, Lieferscheine, Auftragsbestätigungen die von unserer Warenwirtschaft als PDF-Dateien erstellt und in ein definiertes Verzeichnis abgelegt werden.
    Beim Start des Scriptes werden alle emails falsch erstellt. Da wir HTML-email-Versand benutzen, wird zwar das HTML-email Template korrekt aus der DB-Tabelle ausgelesen, der TXT-Teil jedoch fehlt völlig. Dadurch wird die email nicht als "multipart" erkannt. Durch den PDF-Anhang wird der HTML-Code als "plain" interpretiert. Ein Umschalten zwischen TXT-email und HTML-email ist im email-Client nicht möglich. Der Anhang läßt sich öffnen.

    Folglich mußte es einen Bug in cseo-Funktionen und/oder Smarty selbst geben.
    Letzlich gab es zwei Stellen an denen ich die Fehler korrigieren mußte.

    1. Smarty resource plugin
    Für cSEO wurden zwei customized plugins erstellt, jeweils für HTML und TEXT. Diese Dateien liegen hier:
    /includes/classes/Smarty_2.6.26/cseo_plugins (resource.html.php, resource.text.php)
    In resource.text.php hat die erste Funktion einen falschen Namen (falsch: smarty_resource_txt_template) und das selectete Feld wird nicht an die Smarty-Variable übergeben.
    Die erste Funktion muß folglich lauten:

    Code
    function smarty_resource_txt_source ($tpl_name, &$tpl_source, &$smarty_obj) {	$tpl_data = xtc_db_fetch_array(xtc_db_query(" SELECT email_content_text FROM emails WHERE email_name = '".$tpl_name."' AND languages_id = '".$_SESSION['languages_id']."' "));	if (sizeof($tpl_data) == 1) {		$tpl_source = $tpl_data['email_content_text'];		return true;	} else {		return false;	}}


    Dies behebt aber den eigendlichen Fehler nicht, denn nun wird nur die erste email falsch erzeugt. Alle weiteren emails werden nun auch von der Struktur korrekt aufgebaut. Und das innerhalb einer while-Schleife - komisch.
    Also weiter gesucht.

    2. cSEO Funktion im inc-Verzeichnis
    In der Datei "cseo_get_mail_body.inc.php" findet man alle Funktionen aus den o.a. Smarty-Plugins wieder und teilweise inklusive der Fehler.
    Außerdem werden hier die resourcen erneut in Smarty registriert. Dies ist nicht nötig nach der o.a. Korrektur.
    Generell können alle Funktionen und die Smarty->register_resource(....) und signatursmarty->register_resource(...) entfernt werden.
    In dieser Datei bleibt also übrig:

    Das war's. Jetzt klappt es.
    Die übertragene email wird in meinem Webmail-Programm als TEXT angezeigt. Im Footer bei "Anhänge" erscheinen zwei Einträge:
    1. untitled-[1.2] als [txt/html] --> die HTML-email
    2. Auftragsbestaetigung.pdf als [application/octed-strem] --> der Datei-Anhang

    Wer also ebenfalls Probleme bei der email-Erstellung hat, sollte dies einfach mal ausprobieren.
    Vielleicht wurde dieses Problem aber auch schon behoben (jedenfalls nicht in CE), dann bitte kurze Info dazu.

    Kommentare erwünscht.

    Hallo admin,
    der Merkzettel funktioniert bei unserer Lösung auch als Gast, die Löung von julien kenne ich leider (noch) nicht.
    Ebenso kann ein Gast die Merkzettel-Einträge auch in einen Gast-Warenkorb verschieben, einzeln oder alle.
    Ein Gast-Merkzettel wird zum Kunden-Merkzettel nach der Registrierung und/oder Login.
    Alle Attribute werden übernommen.
    Diverse weitere Features, vorallem unser Hack mit den Produkt-Familien.
    Neugierig? - Ausprobieren (siehe #3)... oder noch ein wenig Geduld.
    Sowie ich alle wichtigen Baustellen in unserem Shop geschlossen habe, werde ich meine mögliche Lösung hier veröffentlichen.

    so long
    WindMeUp

    So Julien,
    jetzt habe ich es hoffentlich geschafft.
    Das Problem war, dass bei Gästen in der Session die Attribute verloren gingen. Bei angemeldeten Benutzern tritt das Problem nicht auf, da hier der Merkzettel in der DB gespeichert wird.
    Wenn du willst, kannste ja nochmal testen.
    Danke für diene Mithilfe.
    Gruß
    WindMeUp

    Komisch. Im Firefox funktioniert alles richtig (Plus, Minus, Übernahme in Warenkorb, Einzelnen Artikel in Warenkorb oder kompletten Merkzettel in Warenkorb).
    Auch die Aktualisierung funktioniert im Firefox.
    Warum hat der IE auch hier Probleme (mit den CSS klappt auch nicht alles).
    Übrigens benutzen wir die Attribute etwas anders. Wie du der Produkt-Details Seite entnehmen kannst, suche ich mir über die Attriute den passenden Artikel zusammen. Es gibt bei uns also keine Attribut Aufpreise. Jede Kombination von Attributen holt einen anderen Artikel aus der Datenbank. Jeder Artikel hat eine eigene Artikelnummer, eigenen Preis, etc.
    Die Idee hatte ich auch so schon in einem osCommerce-Shop eingebaut.
    Ganz nette Spielerei, machte alles aber auch komplizierter...

    cu, WindMeUp

    Hallo julien,
    Super. Nur warum "deinen" in groß? In den nächsten Tagen erfährst du MEINE Lösung.
    Ob das dann auch DEINE wird, kann ich nicht wissen, nur deine IST sie sicherlich nicht, da bin ich mir sicher.
    Da ich kein Plus-Kunde bin, habe ich mich auch nicht im Plus-Forum registriert (geht das dann überhaupt?).
    Über die Suche habe ich keine Lösungsansätze gefunden,
    und in der letzten downloadbaren CE-Version (2.0.12) und in der Online-Demo sind nachwievor die entscheidenden Fehler enthalten.
    Woher sollte ich also von einer 2. Version aus dem Plus-Forum wissen?
    Für unseren Shop brauchte ich einen funktionieren Merkzettel.
    Also haben wir wohl parallel am gleichen Problem gesessen.

    Und das mit dem Plus-Forum ist eine gute Idee: Ich habe mich soeben dort registriert. Mal sehen ob ich dort freigeschaltet werde.....

    Der Merkzettel funktioniert übrigens hier: dieZaunexperten.de

    Ich habe jetzt den Merkzettel in der CE Version überarbeitet.
    Dieser funktioniert jetzt wie erwartet, auch mit der korrekten Übernahme der Attribute.
    Da wir in unserem Shop allerdings einige weitere Features benutzen, kann ich diese Änderungen noch nicht 1:1 anbieten.
    Wenn Zeit ist, bereite ich die Änderungen für einen allgemeinen Fix vor.

    Wen es interessiert schreibt mir bitte eine PM.

    So. Jetzt will ich dieses Thema nochmals aufgreifen.
    Die default.php ist nachwievor (und auch in der aktuellen v2.0.11.2ce) nicht korrekt umgesetzt.
    In den Zeilen 36-39 findet man zwar:

    Zitat

    if(GROUP_CHECK == 'true') {
    $group_check_c = "AND c.group_permission_".$_SESSION['customers_status']['customers_status_id']." = 1 "; // Kategorie
    $group_check_p = "AND p.group_permission_".$_SESSION['customers_status']['customers_status_id']." = 1 "; // Produkt
    }


    Diese neuen Variablen werden aber im weiteren Verlauf nicht benutzt.
    Also sollte "$group_check_c" in allen Queries für Kategorien und "$group_check_p" in allen Queries für Produkte eingesetzt werden.
    Der Standard-Filter "$group_check" wird im Script "categories_list.php" vorbelegt und ist auch hier aktiv, somit bei den Produkt-Queries falsch.

    Ich habe die if-Anweisung um eine else erweitert und alle $group_check entsprechend ausgetauscht:

    Jetzt klappt es auch mit dem Nachbarn.... :rolleyes:

    Gibt es irgendwelche Reservierungen von groupIds für bestimmte Module etc.?
    Hintergrund:
    Wie ich sehe, werden die Einträge und Links im Admin-Panel über die gID (groupID) gesteuert. Die Eintragungen dazu liegen in den DB-Tabellen "configuration" und "configuration_group".
    Für verschiedene Module gibt es hierfür wohl schon Reservierungen, z.B. Paypal ->25, SEO Config::cSEO Config ->155, usw.
    Da ich diverse Variablen für unsere Bonitätsprüfung gerne im Admin-Panel verwalten möchte, müßte ich somit eine neue groupID vergeben.
    Um nicht künftig einen Konflikt mit nachträglich installierten Modulen zu provozieren, diese Frage.
    Wenn es nix gibt, dann denke ich mir eine Nummer aus und hoffe, das kein anderer diese Nummer irgendwann ebenfalls benutzt.

    Thx
    Stefan