Beiträge von bernd888

    Hallo,

    ich hab gemerkt das google die durckversion z.b. eines artikels indexiert.
    Kann man dies irgendwie unterbinden? Ich hab jetzt nähmlich ca 17000 Einträge in google, wenn ich site:http://www.shop-muskelaufbau.de eingebe. Davon sind sehr viele Druckversionen/-Ansichten.

    hoffentlich könnt ihr mir helfen :)

    freundliche grüße
    shop

    Hallo,

    hast Du eine robots.txt in der root?

    Die standardmäßige verweigert u.a. das Crawlen der Print-Seiten und sieht bei mir inzwischen so aus :
    Disallow: /cgi-bin/
    Disallow: /shop/*?XTCsid
    Disallow: /shop/* ? sessionid
    Disallow: /shop/de/*?XTCsid
    Disallow: /shop/de/* ? sessionid
    Disallow: /shop/en/*
    Disallow: /shop/commerce_seo_url.php
    Disallow: /shop/address_book.php
    Disallow: /shop/address_book_process.php
    Disallow: /shop/account.php
    Disallow: /shop/account_edit.php
    Disallow: /shop/account_edit_process.php
    Disallow: /shop/account_history.php
    Disallow: /shop/account_history_info.php
    Disallow: /shop/checkout_process.php
    Disallow: /shop/advanced_search.php
    Disallow: /shop/advanced_search_result.php
    Disallow: /shop/checkout_address.php
    Disallow: /shop/checkout_confirmation.php
    Disallow: /shop/checkout_payment.php
    Disallow: /shop/checkout_payment_address.php
    Disallow: /shop/checkout_shipping.php
    Disallow: /shop/checkout_shipping_address.php
    Disallow: /shop/checkout_success.php
    Disallow: /shop/cookie_usage.php
    Disallow: /shop/contact_us.php
    Disallow: /shop/create_account.php
    Disallow: /shop/create_account_guest.php
    Disallow: /shop/create_account_process.php
    Disallow: /shop/create_account_success.php
    Disallow: /shop/display_vvcodes.php
    Disallow: /shop/download.php
    Disallow: /shop/gv_redeem.php
    Disallow: /shop/gv_send.php
    Disallow: /shop/info_shopping_cart.php
    Disallow: /shop/login.php
    Disallow: /shop/logoff.php
    Disallow: /shop/password_double_opt.php
    Disallow: /shop/popup_image.php
    Disallow: /shop/popup_search_help.php
    Disallow: /shop/print_order.php
    Disallow: /shop/print_product_info.php
    Disallow: /shop/privacy.php
    Disallow: /shop/product_notifications.php
    Disallow: /shop/product_reviews.php
    Disallow: /shop/product_reviews_info.php
    Disallow: /shop/product_reviews_write.php
    Disallow: /shop/reviews.php
    Disallow: /shop/shipping.php
    Disallow: /shop/shopping_cart.php
    Disallow: /shop/admin/shop/
    Disallow: /shop/download/shop/
    Disallow: /shop/export/shop/
    Disallow: /shop/import/shop/
    Disallow: /shop/includes/shop/
    Disallow: /shop/pub/shop/
    Disallow: /shop/media/shop/

    Dann gibt es noch bei den Webmaster-Tools von Google unter Site wählen / Website-Konfiguration/ Einstellungen / Parameterbehandlung die Möglichkeit "Parameter" vorzuschlagen, für die eine Indexierung ausgeschlossen werden sollten. Da habe ich dann alles reingepackt, was mir im Index noch"spanisch" vorkam, wie "scaleAmount" etc.

    Google Hinweis dazu:

    Zitat

    Dynamische Parameter wie Sitzungs-IDs, Quelle oder Sprache in Ihren URLs können dazu führen, dass verschiedene URLs auf denselben Content verweisen. So kann zum Beispiel http://www.example.com/dresses?sid=12395923 auf denselben Content verweisen wie http://www.example.com/dresses. Entsprechend Ihren Festlegungen kann Google bis zu fünfzehn spezielle Parameter in Ihrer URL ignorieren. Dies führt zu einem effizienteren Crawling und verringert die Anzahl doppelter URLs. Gleichzeitig bleiben die von Ihnen benötigten Informationen erhalten. Google versucht zwar, Vorschläge zu berücksichtigen, kann aber nicht garantieren, dass sie in jedem Fall befolgt werden.

    Wenn die robots.txt richtig eingestellt ist, müsste das eigentlich genügen.

    Ansonsten lasse ich mit einer kostenlosen Zusatzsoftware "Gsitecrawler von Softplus" noch regelmäßig eine Sitemap der kompletten Website (also Hautpseiten inkl. Shop) erstellen, bei der alle aus meiner Sicht unerwünschten print-Links & Co ausgefiltert werden, bevor sie bei google "gemeldet" wird.

    Bis jetzt klappt das alles ganz gut (seit Mitte Nov. 09 - Toi, Toi, Toi!)

    Gruß
    Bernd

    Alle eure Änderungen in diesem Thread bis zu meinem Eintrag am 08.12.2009 18:17 sind hinfällig und bewirken nichts!
    Ich habe direkt an der Stelle angesetzt wo entschieden wird, diese Meldung in die Session(ausgeben) oder nicht.

    Ich habe das eben noch bei einem Kunden, der wollte den Coupon eingerichtet haben, getestet. Klappt ebenfalls.
    Das ist auch die einzige Passage im Checkout an der diese Meldung an die Session ausgegeben wird. Alles andere ist überflüssig, bzw. hat überhaupt keinen Sinn weil die Meldung dann schon in der Session liegt.

    Ist ja wohl echt komisch, dass der "Muskel-Kollege" und ich beide den Fehler nicht loswerden, obwohl wir Deine Änderung eingebaut haben!???

    Hier übrigens Dein erster Lösungbeitrag v. 08.12.09, der anschließend von Dir wieder gelöscht wurde:

    Wie isses? Haste das auch noch verbaut?

    Gruß
    Bernd

    Hallo,

    gestern haben wir das Anlegen eines Gutscheins als Artikel, das "Kaufen" des Gutscheins, das Versenden und anschließende Einlösen erfolgreich getestet und dachten schon "Alles prima".


    Nun kommt der Spezialfall, wo (scheinbar!) nix geht:

    im Admin gibt es nach Aktivierung des Rabatt+Gutscheinsystems unter Gutscheine/Kupons via Gutschein eMail eine Möglichkeit, an eine E-Mailadresse einen Gutschein zu versenden.

    Der Gutschein (im Test: 10EUR) wurde generiert und kam auch als E-Mail an.
    Nach dem Klicken auf den Link in der Mail, wurde ein Konto angelegt und ein Artikel in den Warenkorb gelegt. Unter der Warenkorbanzeige erschien auch zunächst ein Hinweis, dass ein Guthaben von 10 EUR vorhanden sei.

    Oben erschien die Meldung, dass der Gutscheincode gültig ist.

    Soweit so gut, allerdings wurde der eingelöste Gutschein anschließend nicht vom Warenwert abgezogen!!!
    ------------------------------------------------------------------------------------------------------------------

    Nachtrag/Grund:

    Zahlungsweise Bitte wählen Sie die gewünschte Zahlungsweise für Ihre Bestellung aus.

    (O)- PayPal Kaufabwicklung

    (O)- Vorkasse

    (O)+ 7,60 EURNachnahme

    (O)- EU-Standard Bank Transfer
    Überweisen Sie den Rechnungsbetrag auf unser Konto. Die Kontodaten erhalten Sie nach Bestellannahme per E-Mail


    - Guthaben
    Gutscheine
    Anwählen, wenn Sie Ihr Guthaben verwenden möchten (O)
    -----------------------------------------------------------------------------------------------------------------

    Wenn ich das "Guthabenfeld" am Ende der Zahlungsoptionen schon in der "Eile" des Testens übersehe, wie soll es erst dann unseren Kunden ergehen?
    Bei den Zahlungsweise/Xt Module im BAckend kann man die Reihenfolge der Zahlungsmöglichkeiten ändern. Leider sind die Gutscheine nicht dabei.

    Habe ihr eine Lösung, wie ich die Anzeige der Gutscheinoption im Falle eines Guthaben in der Darstellung beim checkout_payment ganz nach oben bekomme?


    ???
    Bernd E.

    Bei mir nicht. Beim ersten mal ja. Nach dem schliessen des Browsers, man bedenke die Session, ging es dann.
    Habe das auch auf einem zweiten Shop geprüft, klappte ebenfalls.

    Bei mir wurden die ct_coupon.php sowie die checkout_confirmation.php (2x unset etc.) Deinen Vorschlägen entsprechend angepasst und der Meldungstext in der german.php wieder auf den alten Stand gebracht.
    Danach wurde der USer abgemeldet, das Browserfenster geschlossen - alles erneut aufgemacht, wieder angemeldet, neuer Warenkorb, neue Rabatt-Kupon-Eingabe.

    Danach gab es schon bei der Seite mit Anzeige des Warenkorbs oben die bekannte Meldung "Sie haben leider keinen...usw.".
    checkout_shipping=>keine Meldung
    checkout_payment=>alte Fehlermeldung - s.o.
    checkout_confirmation=>keine Meldung

    Gestern abend erhielt ich eine Änderungsmail für diesen Thread mit einem inzwischen von Dir gelöschten Beitrag, wo Du als Lösung etwas in irgendeiner gift_cart.php oder .html zur Vermeidung der o.a. Meldung geändert hattest (E-mail ist auf meinem Account zuhause). Kann es sein, dass Du diese hier nicht mehr nachlesbare Änderung ebenfalls bei beiden Testshops umgesetzt hast und sich unsere Dateiversionen (gift_cart-mäßig) insoweit zusätzlich unterscheiden?

    Das wäre für mich eine mögliche Erklärung des unterschiedlichen Verhaltens.

    Zweite Möglichkeit: Du verwendest den Gutschein und nicht den Rabattkupon (wohl eher unwahrscheinlich, wurde hier aber schon ein paar mal verwechselt)

    Gruß
    Bernd E.

    Danke für den Tipp Bernd :)

    Es funktioniert, ich habe die vorgenommenen Einstellungen mit unset so gelassen. Ich glaube es hat KEINEN großen Sinn sich jetzt noch mit dem System rumzuschlagen, weil bald die V2 kommt und dort das Koupon und Gutscheinsystem läuft, sofern die Informationen stimmen. :p

    Zu der Rechnung des Rabatts:

    In meinem Shop befinden sich einige Produkte mit 19% und 7%. Eben habe ich einen Testkauf durchgeführt, der Shop rechnet die Preise richtig aus und der Rabatt weicht nur geringfühgig ab (ca. 3 cent), liegt wahrscheinlich an der Rundung von Gleitzahlen. Was für den Kunden zu verkraften ist. :D

    Bei einem Bücherkauf von 74,70 ist die Differenz bei der Mwst bei mir schon fast 1EUR, also ein wenig mehr als zu verkraften - ausser bei den privaten Kunden, denen ist es egal und wir schicken ohnehin eine Rechnung aus unserer Wawi (....u. Gottseidank nicht aus dem Shop).

    Blöd ist nur, dass wir im Shop auch andere Kundengruppen haben (z.B. Händler) und da wird die Rechnung noch ein wenig komplizierter. Deine modifizierte ot_coupon.php kam nach meinen Test den richtigen Ergebnissen am nächsten.

    daniel S.=> wenn die V2 in Sachen Rabattkupons auf dem gleichen Mist basiert, der von os-commerce bis heute da vor sich hindümpelt, gehen wir Dir damit bestimmt wieder auf die Nerven (...auch wenn wir bis dahin PHP gelernt haben sollten)!

    Gruß
    Bernd

    PS: wir haben uns Euren Gutscheingenerator gekauft. Den habe ich bislang noch garnicht einbauen können, weil mich das ot_coupon-Chaos aufgehalten hat.>:(

    das musst Du bei Gutschein erstellen definieren, da gibt es die Möglichkeit zu sagen, dass mit oder ohne UST gerechnet wird.


    Leider ist es nicht ganz so einfach, wie die "Einstellmöglichkeiten" einem suggerieren.

    ...ich bin erst beim Rabattkupon (zum Gutschein komme ich noch). Ein Rabattkupon reduziert den Umsatz prozentual oder um einen Fix-Betrag, so dass die MwSt von diesem neuen Umsatz ausgehend zu berechnen ist.

    Wenn ich die Einstellungen für die im anderen Thread veröffentlichte modifizierte Version des Modul ot_coupon (->Backend/Module/Zusammenfassung) so vornehme:

    Rabatt Kupon
    Wert anzeigen: true
    Sortierreihenfolge: 40
    Inklusive Versandkosten: true
    Inklusive MwSt: true
    MwSt. neu berechnen: Standard
    MwSt.-Satz: Standardsatz (->19%)

    Privatkunde:

    Zwischensumme: 99,00 EUR
    Versandkostenfrei: 0,00 EUR
    Rabatt Kupons:a-test:- 10,00 EUR
    inkl. UST 19%: 14,21 EUR (richtig, d.h. 19% von 74,79EUR=>100%, 119%=>89EUR)
    Summe: 89,00 EUR

    ...stimmen zwar die MwSt. und das Bruttoergebnis, aber nur solange wie ich im Warenkorb z.B keine Bücher habe (7% MwSt).

    Da ich kein zweites Modul habe, um für eine zweite Artikelsorte andere MwSt.- Einstellungen vornehmen zu können, kann ich diese Art der MwSt-Berücksichtigung nicht einsetzen.

    Bei Händlerkunden mit Nettoanzeige kommt dann so etwas raus:

    Summe, netto: 57,00 EUR
    Rabatt Kupons:a-test:- 10,00 EUR
    zzgl. UST 19%: 9,23 EUR (richtig wäre 8,93, 19% v. 47EUR)
    Summe, brutto: 56,23 EUR (richtig wäre 55,93, d.h. 47+8,93EUR)

    Tja, die 19% von 47 EUR sind nun mal 8,93 und nicht 0,3 EUR mehr.
    ---------------------------------------------------------------------
    *********************************************************************
    ---------------------------------------------------------------------

    Mit Eurer Original ot_coupon.php:

    Privatkunde:

    Zwischensumme: 99,00 EUR
    Versandkostenfrei: 0,00 EUR
    Rabatt Kupons:a-test:- 10,00 EUR
    inkl. UST 19%: 15,81 EUR
    Summe: 89,00 EUR

    und den Einstellungen:

    Wert anzeigen:true
    Sortierreihenfolge:40
    Inklusive Versandkosten:true
    Inklusive MwSt:false
    MwSt. neu berechnen:None
    MwSt.-Satz:--keine--

    ....stimmt nur die Bruttoendsumme. Die MwSt wird immer noch vom nicht reduzierten Betrag gerechnet.

    Mit geänderten Einstellungen:
    Wert anzeigen: true
    Sortierreihenfolge: 40
    Inklusive Versandkosten: true
    Inklusive MwSt: true
    MwSt. neu berechnen: Standard
    MwSt.-Satz: Standardsatz (->19%)

    kommt dann das dabei heraus:

    Zwischensumme: 99,00 EUR
    Versandkostenfrei : 0,00 EUR
    Rabatt Kupons:a-test:- 10,00 EUR
    inkl. UST 19%: 14,21 EUR
    Summe: 87,40 EUR

    Mwst wurde zwar richtig vom um 10EUR reduzierten Brutto (89EUR) gerechnet, aber dafür stimmt die Bruttosumme nicht mehr.

    Bei Händlerkunden mit Nettoanzeige und den gleichen Einstellungen:

    Ergebnis:
    Summe, netto: 57,00 EUR
    Rabatt Kupons:a-test:- 10,00 EUR
    zzgl. UST 19%: 10,83 EUR
    Summe, brutto: 57,83 EUR

    D.H. die MwSt wird vom nichtreduzierten Preis berechnet. Danach wird die Bruttosumme (67,83) um den Kupon von 10EUR vermindert.
    Die ausgewiesene Steuer ist damit wieder "zu hoch", da sie von 47EUR (tatsächlichem u. besteuerungsfähigem) Umsatz ausgehend hätte berechnet werden müssen. Die richtige Bruttosumme wäre (119% v. 47EUR)= 55,93EUR


    ------------------------------------

    Bislang rechnet keine Version der ot_coupon.php in allen Fällen richtig oder ist für alle Fälle geeignet (s. 7 oder 19% Problem)

    Das I-Net ist voll von solchen Problembeschreibungen betr. Rabattkupons und deutscher MwSt seit os-commerce, gelöst hat es wohl noch niemand - oder?

    cu
    Bernd

    Hallo,

    da zu viele nützliche Fehlermeldungen mit unterdrückt wurden, habe ich die "unset" - Anweisungen aus den genannten Dateien (bis auf die in der checkout_confirmation.php) wieder herausgenommen (s. auch->hier und hier).

    Stattdessen habe ich einen anderen Weg gewählt, um die "Sie haben leider keinen Code eingegeben"-Meldung wegzukriegen. Da diese Meldung für mich bei den normalen Bestellvorgängen wahrscheinlich nie vorkommen sollte, habe ich die Meldung einfach in der lang\german\german.php gekillt.

    Also...suchen nach :

    PHP
    define('ERROR_NO_REDEEM_CODE', 'Sie haben leider keinen Code eingegeben.');

    und ersetzen durch:

    PHP
    define('ERROR_NO_REDEEM_CODE', '');

    Brutal, aber wirksam! :D

    Gruß,
    Bernd E.

    Hallo,

    wie gestern schon an anderer Stelle erwähnt, rechnet das Kupon-System im Moment so:

    B-DEMO 119,00 EUR

    -----------------------------------------------------------

    Zwischensumme: 119,00 EUR
    Selbstabholung (Selbstabholung der Ware in unserer Geschäftsstelle.): 0,00 EUR
    inkl. UST 19%: 19,00 EUR
    Rabatt Kupons:test1:- 10,00 EUR
    Summe: 109,00 EUR


    Das Endergebnis ist auch stimmig, aber die MwSt. müsste (im Gegensatz zum Gutschein) vom reduzierten Betrag berechnet werden, weil der Kupon den konkreten Umsatz hier mindert und damit auch die Umsatzsteuer (neu: 17,40EUR, d.h. 19% von 109,-EUR).

    Wie kriegt man das hin?
    Im I-net (os-commece-Foren + xt-commerce-Foren) ist das schon in ca. 2006 bemängelt worden, aber bislang scheint es keiner abgestellt zu haben.

    ???
    Bernd

    ...im Backend : Kunden/Bestellungen ...An Admin erneut versenden...

    erzeugt keine Email an den Admin sondern das :

    Fatal error: Cannot redeclare class xtcPrice in /www/htdocs/MeinAccount/shop/includes/classes/xtcPrice.php on line 30

    Dasselbe passiert, wenn man auf "An Kunden erneut versenden" klickt!!!?

    ???
    Bernd

    PS: ...das ->hier (require_once) hat nicht geholfen, In meiner /admin/order.php war übrigens nur ein require (DIR_FS_CATALOG.DIR_WS_CLASSES.'xtcPrice.php');

    Hallo,

    beim Speichern eines offenen Warenkorbes (z.b. nach Änderung der Versandadresse) kommt das:

    Warning: constant() [function.constant]: Couldn't find constant MODULE_SHIPPING_D_TAX_CLASS in /www/htdocs/MeinAccount/shop/admin/orders_edit.php on line 532

    Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00ba551/shop/admin/orders_edit.php:532) in /www/htdocs/MeinAccount/shop/admin/includes/functions/general.php on line 130

    Zeile 532 beinhaltet (ab 531):

    PHP
    if ($module_tmp_name != 'selfpickup') {
    					$module_tax_class = constant(MODULE_SHIPPING_.strtoupper($module_tmp_name)._TAX_CLASS);
    				} else {
    					$module_tax_class = '';
    				}

    Selfpickup ist zwar installiert - steht aber in der Einstellung auf "false", kann also garnicht ausgewählt worden sein, weil der Kunde (Gastkonto) es nicht zu Gesicht bekam. Trotzdem stehen die Versandkosten in jeder nachbearbeiteten Bestellung erst einmal auf d: und 0.0000

    ???
    Bernd

    Das schien ebenfalls noch einfach zu sein:

    shopping_cart.php:
    suche:

    PHP
    require_once (DIR_FS_INC.'xtc_recalculate_price.inc.php');

    füge danach ein:

    PHP
    unset($_SESSION['error_message']);   
    unset($_SESSION['info_message']);

    Was das für Nebenwirkungen auf das Errormeldesystem haben kann, wird sich vermutlich noch zeigen (z.B. gibt es leider nun keine Meldung mehr, wenn ein ungültiger code eingegeben wurde!).

    EDIT -> 08.12.2009

    Anscheinend werden die Müllmeldungen wie "Sie haben leider keinen Code eingegeben" in der Datei xtc_collect_posts.inc.php im inc-Verzeichnis erzeugt, die ich allerdings noch nicht so ganz durchblicke (Daniel S. , wie wärs?).

    Ansonsten ackere ich mich gerade durch die Coupon/Kupon-Probleme durch bevor ich zum eigentlichen Gutschein komme.

    Dabei gibts viele offene Fragen hinsichtlich der Berechnungsmodi (vor allem bei der Berechnung der MwSt)...
    wie z.B.
    Zwischensumme: 69,00 EUR
    Pauschale Versandkosten (Bester Weg): 3,90 EUR
    Rabatt Kupons:xxxx:- 10,00 EUR
    inkl. UST 19%: 11,64 EUR
    Summe: 62,90 EUR

    Die ausgewiesenen 11,64/19% beziehen sich offenbar auf die nicht reduzierte Summe von 69+3,90=72,90. D.H. Endsumme (Artikel ./. Kupon) stimmt zwar, aber eine ausgewiesene MwSt von der Endsumme gibt es nicht.

    (Bei Nettopreiskunden wird es noch fraglicher.)

    Ferner wurde die Eingabe/Verabeitung von Kategorien und Artikelserien für die ein Kupon gültig sein soll, von unseren Programmierspezies hier noch nicht aus der alten Welt der cpaths und ids in die neue schöne Seo-url-Welt übertragen. D.H. Du kannst da bei einem Kupon für die Gültigkeitsweite an Kategorienamen/urls und Produkturls eingeben, was Du willst und es bleibt bei "None" , weil du besagte kryptische Altbezüge nicht vernünftig ermitteln und eingeben kannst.


    Gruß
    Bernd E.

    EDIT->08.12.2009

    Hallo,

    bei mir hielt sich die blöde Fehlermeldung "Sie haben leider keinen Code eingegeben" trotz richtiger Codeeingabe und aller hier propagierten Änderungen u. Ergänzungen bis auf die checkout_payment-Seite.

    Ich habe soeben der Einfachtheit halber auch in der checkout_payment.php folgende Einträge (Posting v. Daniel S.) ergänzt:

    suche:

    PHP
    require_once (DIR_FS_INC . 'xtc_check_stock.inc.php');

    füge danach ein:

    PHP
    unset($_SESSION['error_message']);   
    unset($_SESSION['info_message']);

    Jetzt klappt es wenigstens schon einmal ohne die nervige Fehlermeldung!

    Gruß
    Bernd E.

    Hab hier gerade in einem anderen Forum was gefunden, was eine Lösung enthalten könnte:

    Link nicht mehr existent!
    ...oder per copy&paste:

    Zitat

    Das Problem stellt der SSL Proxy da. https://ssl-account.com/motivspiegel.de/

    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^Hier die IP von deinem SSL Proxy rein [NC]
    RewriteCond %{HTTP_HOST} ^domain-name\.de$ [NC]
    RewriteRule ^(.*)$ http://www.domain-name.de/$1 [L,R=301]

    In anderen Shop Systemen funktioniert es so. Sollte bei xtc auch klappen.


    85.13.128.137 müsste die Ip von https://ssl-account.com/ sein. Herausfinden kannst du die IP indem man die phpinfo.php mal über https aufruft!

    Gruß,
    Bernd E.

    Hallo,

    die .htaccess habe ich in einem Testshop probiert; sie funktionierte auf meinem Server auch zunächst anscheinend und ohne die 400-Fehler.

    Allerdings ist mir aufgefallen, dass bei eurem Server bei der Umleitung auf "www" etwas nicht stimmt. Das muss zwar mit dem 400-Fehler bei den Kategorien pp nichts zu tun haben....., aber wer weiss.

    Der Aufruf "http://lapshop24.de/Testshop/" erzeugt einen 404-Fehler, d.h. "http://www.lapshop24.de/404.php"
    (+ folg. Smarty-Meldung: Warning: Smarty error: unable to read resource: "div16_cs_blue/module/404.html" in /kunden/104174_48366/Testshop/includes/classes/Smarty_2.6.26/Smarty.class.php on line 1093")

    Geht man in die root und testet den Aufruf "http://lapshop24.de", wird "http://www.lapshop24.de//" erzeugt, d.h. noch ein "/" angehängt.

    Vermutlich habt ihr für die root der domain noch eine .htaccess, was nix Schlimmes ist, wenn sie denn keine Fehler enthält, die ein überflüssiges "/" erzeugen.

    Gruß,
    Bernd E.