Beiträge von Joerg2010

  • whats_new.php vs. products_new.php...

    Mir ist ein weiterer offensichtlicher Bug aufgefallen.

    In der Box "Neue Artikel" wurden bei mir Produkte angezeigt, der Kunde klickt auf "Alle neuen Produkte" und dort erscheint der Artikel aber nicht, der in der Box angezeigt war.

    Die Ursache war schnell gefunden, denn in der Box wurde das Datum gar nicht abgefragt.

    Vor:

    if ($random_product = xtc_random_select("select distinct....

    einfügen:

    if (MAX_DISPLAY_NEW_PRODUCTS_DAYS != '0') {
    $date_new_products = date("Y.m.d", mktime(1, 1, 1, date(m), date(d) - MAX_DISPLAY_NEW_PRODUCTS_DAYS, date(Y)));
    $days = " and p.products_date_added > '".$date_new_products."' ";
    }

    und SQL-Statement erweitern:

    if ($random_product = xtc_random_select("select distinct
    p.products_id,
    p.products_image,
    p.products_tax_class_id,
    p.products_vpe,
    p.products_vpe_status,
    p.products_vpe_value,
    p.products_weight,
    p.products_price
    from ".TABLE_PRODUCTS." p, ".TABLE_PRODUCTS_TO_CATEGORIES." p2c, ".TABLE_CATEGORIES." c
    where p.products_status=1
    and p.products_id = p2c.products_id
    and p.products_id !='".(int) $_GET['products_id']."'
    and c.categories_id = p2c.categories_id
    ".$group_check."
    ".$fsk_lock."
    ".$days."
    and c.categories_status=1 order by
    p.products_date_added desc limit ".MAX_RANDOM_SELECT_NEW)) {

  • addressformat error in payment/shipping addresses

    Ich hab das jetzt im Sinne der Kundenfreundlichkeit so gelöst (shipping und payment):

    if ($addresses_count # < MAX_ADDRESS_BOOK_ENTRIES) {

    geändert in

    if ($addresses_count == 1){

    Begründung / Denkansatz:

    a )Wenn der Kunde mehrere Adressbucheinträge hat, werden ihm nur diese zur Auswahl angezeigt.
    b) Hat er nur eine (seine eigene) Adresse und klickt auf "Adresse ändern", kann er eine abweichende eingeben. Beim nächsten Mal ist diese ja im Adressbuch und a) greift.

    Ich habe nur private Kunden, d.h. in der Regel wird der Kunde nur in sehr seltenen Fällen mal wo anders hin liefern lassen, z.B. an seinen Arbeitsplatz oder zum Nachbarn.

  • Evtl. Bug in Session-Prüfung

    in der application.top.php

    // verify the ssl_session_id if the feature is enabled
    if (($request_type == 'SSL') && (SESSION_CHECK_SSL_SESSION_ID == 'True') && (ENABLE_SSL == true) && ($session_started == true)) {
    $ssl_session_id = getenv('SSL_SESSION_ID');
    ... usw.

    getenv('SSL_SESSION_ID') ist nie etwas enthalten, somit, die SSL_SESSION_ID immer false...

  • addressformat error in payment/shipping addresses

    Noch eine Frage fällt mir ein:

    Welches sind, insbesondere im Hinblick auf Sicherheit, die idealen Einstellungen im Admin unter "Sessions"?

    Finde nur Stichpunkte und nichts, wo es detailliert erklärt ist.

    Bei mir aktuell:

    Speicherort: /tmp
    Cookies: false
    Checken SSL: true
    User Browser: true
    IP-Adresse: false
    erneuern: true

  • addressformat error in payment/shipping addresses

    in der Datei /shopping_cart.php suchen nach:

    $smarty->assign('FORM_ACTION', xtc_draw_form('cart_quantity', xtc_href_link(FILENAME_SHOPPING_CART, 'action=update_product')));

    ersetzen durch:

    $smarty->assign('FORM_ACTION', xtc_draw_form('cart_quantity', xtc_href_link(FILENAME_SHOPPING_CART, 'action=update_product', 'SSL')));

  • Kosmetisches Problem

    Also nochmal als Zusammenfassung, ich halte hier eine Verbesserung im Sinne der Kundenfreundlichkeit für dringend nötig:

    - so wie ich es sehe, soll der Bestellprozeß auch bei abgeschaltetem Javascript funktionieren (ich weiß, JS ist heute fast unerlässlich, aber es ist nunmal vorgesehen, dass es auch ohne JS funktionieren soll)

    - Ist JS aus, erfolgt zwar eine Fehlerprüfung, jedoch wird trotz Fehler der redirect auf die checkout_shipping ausgeführt und einfach die Standardadresse des Kunden verwendet. Wenn der Kunde wie gesagt nicht darauf achtet, wird ggf. an die falsche Lieferadresse geliefert.

  • Kosmetisches Problem

    Jetzt fällt mir doch noch was auf, wenn der User nun eine erste neue Lieferadresse eingeben will, hat er, wenn die Javascript-Prüfung an ist, keinen BACK_BUTTON, da dieser nur bei process = true kommt.

    Er kommt also nur über Browser-Back zurück.

  • Kosmetisches Problem

    Gleiches passiert z.B. auch auf der address_book_process

    Die Frage ist auch, warum in der header.php per

    if (strstr($PHP_SELF, FILENAME_ADDRESS_BOOK_PROCESS )) {
    if (isset($_GET['delete']) == false) {
    #include('includes/form_check.js.php');
    }
    }

    das js-file eingebunden wird, wenn die form-action keinen onsubmit bekommt. M.e. kann das require weglassen, da die Prüfung ohnehin serverseitig erfolgt. Oder in die Form-Action muss das Submit!

    In der checkout_shipping_address und checkout_payment_address jedoch erfolgt keine Prüfung, wenn eine neue Adresse eingegeben wird. Fehlt was, wird einfach die Standardadresse genommen, was ich für einen echten Bug halte, da die Lieferung fehlgeleitet würde, wenn der Kunde nicht bemerkt, dass die Standardadresse genommen wird!

  • Kosmetisches Problem

    Nur eine winzige Kleinigkeit, aber auch kleine Fehler sollten nicht sein:

    Ich habe festgestellt, dass auf Seiten, auf denen die

    form_check.js.php

    per require dazugeladen wird, das Layout um ca 10-15 Pixel nach unten rutscht. Ist im IE und FF so.

    Weiß jemand, wie man das verhindern kann?