Beiträge von Mario_b

    hast du ggf neue zahlungs- oder versandmodule installiert? bitte überprüf mal alle involvierten Dateien, ob an deren Ende noch ein " ", also leerzeichen oder ähnliches, hinter dem schließenden php-tag steht.

    Ja, es werden echt viele und ich bin mir sicher, dass es meinem Projekt bei google zumindest nicht ZUTRÄGLICH ist wenn ich nach und nach genausoviele 404er wie Produkte habe... es wäre also wünschenswert, dass diese Art von Bugs demnächst mal ein Ende haben, solche Fehler schaden nicht dem einzelnen Sale, sondern wirken sich direkt auf das ganze Projekt aus.

    Moin, in der commerce:SEO v2.1.1.5 Plus ist noch ein ziemlich gemeiner Bug versteckt, und zwar wird im Quelltext der Produktdetailseiten durch das {JAVASCRIPT_FORM_ACTION} Smarty folgendes generiert:

    <script> function onsubmitform(){ document.cart_quantity.action ="http://www.v21plus.de/RAM-16-GB-Demo-2.htmlaction=add_product"; return true;} </script>

    hier fehlt das Fragezeichen zwischen html und action, der Googlebot verfolgt diese Links und in den Webmastertools meiner Kunden tauchen jetzt tausende Crawlingfehler auf (404, klar diese "URL" gibts ja auch nicht).

    Quickfixen lässt sich das in der includes/modules/product_info.php

    $info_smarty->assign('JAVASCRIPT_FORM_ACTION', '<script> function onsubmitform(){ document.cart_quantity.action ="'.xtc_href_link(FILENAME_PRODUCT_INFO, xtc_get_all_get_params(array('action'))) . '?action=add_product"; return true;} </script>')

    Fragezeichen an die markierte Stelle setzen hilft erstmal, allerdings erschließt sich mir das ganze noch nicht wirklich, hat das script eigentlich noch eine funktion? weil ein Aufruf der korrigierten http://www.v21plus.de/RAM-16-GB-Demo…ion=add_product führt nicht dazu, das betroffene Produkt in den WK zu legen.

    habs 3 mal angefangen, einmal davon hinbekommen, aber mit nem uralt cseo.

    ist schwierig das Ding in den 1page checkout zu integrieren, mit dem "normalen" checkout gehts, aber wer will den schon.

    Alternative jetzt bei mir: paymorrow, das ließ sich besser anpassen, also auch mit 1page checkout.

    Moin,

    ich hab mir `n Modul gebaut, welches m.E. eine schmerzlich vermisste Option nachliefert, nämlich Sonderangebote auf der Startseite anzeigen zu lassen, ohne diese jedesmal auch dahinverlinken zu müssen, d.h. es wird quasi der Inhalt der specials-box ausgegeben, ist aber separat über den Listenmanager steuerbar.

    Zusätzlich, kann das Modul auf Kategorie-Ebene eingesetzt werden, somit werden beim Aufruf einer Kategorie, die dort enthaltenen Sonderangebote zuoberst dargestellt (wiederum steuerbar über den listen-manager, unabhängig von den Einstellungen für die Index-ebene).

    Da ich mit dem Gedanken spiele, das Modul demnächst auch anderen für`n Obulus zur Verfügung zu stellen , würde mich an dieser Stelle interessieren welche Einstellungen für euch dabei interessant wären, d.h. wonach würdest ihr die Darstellung sortieren können wollen? Aktuell habe ich nur die Sortierung "bald endene Angebote" ASC/DESC und eben die maximale Anzahl der jeweils anzuzeigenden Produkte - Freue mich über Anregungen :)

    Zu sehen ist das ganze hier bei einem Kunden: http://www.saucen-welt.de und auf einigen Unterkategorien wie http://www.saucen-welt.de/Asiatisch/ (wo keine Specials liegen, wird das Modul auch nicht eingeblendet).
    Der Hinweis "Unsere Sonderangebote im Dezember" wird automatisch angepasst, d.h. man muss da auch nicht jeden Monat wieder ran.

    Freue mich auf Feedback!

    Mit besten Grüßen

    Mario

    Moin,

    ich hab mir `n Modul gebaut, welches m.E. eine schmerzlich vermisste Option nachliefert, nämlich Sonderangebote auf der Startseite anzeigen zu lassen, ohne diese jedesmal auch dahinverlinken zu müssen, d.h. es wird quasi der Inhalt der specials-box ausgegeben, ist aber separat über den Listenmanager steuerbar.

    Zusätzlich, kann das Modul auf Kategorie-Ebene eingesetzt werden, somit werden beim Aufruf einer Kategorie, die dort enthaltenen Sonderangebote zuoberst dargestellt (wiederum steuerbar über den listen-manager, unabhängig von den Einstellungen für die Index-ebene).

    Da ich mit dem Gedanken spiele, das Modul demnächst auch anderen für`n Obulus zur Verfügung zu stellen , würde mich an dieser Stelle interessieren welche Einstellungen für euch dabei interessant wären, d.h. wonach würdest ihr die Darstellung sortieren können wollen? Aktuell habe ich nur die Sortierung "bald endene Angebote" ASC/DESC und eben die maximale Anzahl der jeweils anzuzeigenden Produkte - Freue mich über Anregungen :)

    Zu sehen ist das ganze hier bei einem Kunden: http://www.saucen-welt.de und auf einigen Unterkategorien wie http://www.saucen-welt.de/Asiatisch/ (wo keine Specials liegen, wird das Modul auch nicht eingeblendet).
    Der Hinweis "Unsere Sonderangebote im Dezember" wird automatisch angepasst, d.h. man muss da auch nicht jeden Monat wieder ran.

    Freue mich auf Feedback!

    Mit besten Grüßen

    Mario

    Hm da wirst du wahrscheinlich wirklich auf die Hersteller bzw Verkäufer des Moduls setzen müssen, es sei denn ein anderer User hier hatte dasselbe Problem (ich hab das Modul bei keinem meiner Kunden im Einsatz, daher kann ich hierzu leider nichts sagen, müsste ich mir das auch erst ansehen)

    Die aktuelle Umsetzung des Gutscheinmoduls ist kaum zu gebrauchen leider, bei Gutscheinen des Typs "Festbetrag-Gutschein", läuft fast alles schief weil die ganzen Punkte, die du im Adminbereich bestimmst, also verwendung pro Kunde, Verwendung des Gutscheins insgesamt usw überhaupt nicht abgefragt werden.
    Hier `n Quickfix, was aber das Problem nur aufschiebt und nicht die entgültige Lösung ist, also nur machen, wenn schon Gutscheine imUmlauf sind, die jetzt beliebig oft (aber nur einmal pro kunde) eingesetzt werden sollen:

    Um das deaktivieren nach einmaliger einlösung zu killen: /inc/coupon_mod_functions.php : um Zeile 94 :
    // GUTSCHEIN DEAKTIVIEREN
    $gv_update = xtc_db_query("update " . TABLE_COUPONS . " set coupon_active = 'N' where coupon_id = '" . $coupon['coupon_id'] . "'");

    einfach auskommentieren, danach hast du dieses Problem schonmal erschlagen ;)

    ich muss leider grad dringend los, aber evtl nimmt sich ja admin/nico des Themas noch abschließend an, also es müssen noch in der inc/xtc_collect_posts.inc.php sowie der gv_redeem.php änderungen vorgenommen werden, und zwar an der Stelle, wo überprüft wird, ob der Gutschein bereits eingelöst wurde - hier fehlt nämlich jegliche abfrage, WELCHER Kunde den Gutschein bereits eingelöst hat, d.h. wurde der Gutschein von Kunde A eingelöst, bekommen alle weiteren Kunden die Nachricht "ungültiger Gutscheincode" - schöner Mist! ;)

    Mein qf dafür sieht so aus
    // ERROR : GUTSCHEIN BEREITS EINGELÖST
    $redeem_query = xtc_db_query("select * from " . TABLE_COUPON_REDEEM_TRACK . " where coupon_id = '" . $gv_result['coupon_id'] . "' AND customer_id= '" . (int) $_SESSION['customer_id'] . "' limit 1");
    if (xtc_db_num_rows($redeem_query) != 0) {
    xtc_redirect(xtc_href_link(FILENAME_SHOPPING_CART, 'info_message=' . urlencode(ERROR_ALREADY_REDEEMED_GV), 'SSL'));
    }

    Wichtig dabei : die ERROR_ALREADY_REDEEMED_GV ist neu von mir, da ich es unglücklich fand, nur "ungültiger gutscheincode" zu sagen, wenn der code eigentlich ok ist und die Fehlermeldung "gutschein wurde bereits eingelöst" lauten sollte.

    Wie gesagt, das hier ist nur`n quickfix und muss nochmal richtig überarbeitet werden...