"Versandkostenfrei" steht mit der "0" schon ganz "oben".
Die aktuellen Einstellungen der Sortierreihenfolge:
Versandkostenfrei freeamount 0
Pauschale Versandkosten flat 1
Selbstabholung selfpickup 2
Versandkosten nach Zonen zones 3
Tabellarische Versandkosten table 4
Hallo,
wir haben folg. Versandkostenmodule in unserem Shop kundengruppenabhängig installiert:
flat
freeamount
selfpickup
table
zones
Versandkostenfrei sind solche Artikel über 60EUR. Ansonsten haben wir für Deutschland die Pauschale von 3,90EUR.
Leider bringt google-shopping unsere Artikel immer mit dieser Pauschale heraus.
In der xml-Datei findet sich hierfür die vorläufige Ursache darin, dass bei den versandkostenfreien Artikeln zwei "Versandblöcke" definiert sind: einer mit der Kostenpauschale und danach einer mit "Versandkostenfrei" und 0EUR Kosten.
Google liest nur den ersten und weist die wegen des Artikelpreises in vielen Fällen unzutreffenden Pauschale mit aus.
Abhilfe?
Gruß
Bernd E.
Beispiel:
<g:preis> 75,00 EUR</g:preis>
<g:menge>500</g:menge>
<g:zustand>neu</g:zustand>
<g:versand>
<g:land>DE</g:land>
<g:region></g:region>
<g:service>Pauschale Versandkosten</g:service>
<g:preis>3.9</g:preis>
</g:versand>
<g:versand>
<g:land>DE</g:land>
<g:region></g:region>
<g:service>Versandkostenfrei</g:service>
<g:preis>0</g:preis>
</g:versand>
</item>Hallo,
soeben fiel es mir wie Schuppen von den Augen, dass die Zeitstempel in der Datenbank mit den Zeiten diverser Bestellungen identisch sind. Ich werde dann mal die Fehlersuche in den checkout_*.php-scripten fortsetzen, wo einige hier mit mir zusammen heftigst rumgebastelt haben, um die Gutscheingeschichten rund zu bekommen.
Gruß
Bernd E.
Hi,
nachdem ich schon >300 DB-Einträge manuell gelöscht habe, versuche ich nun die Ursache für die Geister-Coupons einzukreisen. Dabei hoffe ich durch Auswertung der Log-Dateien des Servers herauszufinden, ob irgendjemand oder irgendetwas (bots) zu den teilweise exotischen Zeiten auf Dateien des Gutschein/Coupon-Systems (inkl. Gutscheingenerator) zugreift und die Einträge hinterlässt.
Die Einträge in den Tabellen coupon_email_track und coupon sehen folgendermaßen aus: siehe Link auf externe Bilddatei
Vielleicht kann jemand schon anhand der DB-Einträge sehen/vermuten, wo das Zeugs herkommen könnte!?
Gruß
Bernd E. 
Hi,
in den letzten Monaten fällt mir beim Sichern der DB auf, dass die Datenbankgröße zügig zunimmt, und zwar von ca. 3,9 mb (ohne slimstat) auf ca. 26 mb (mit mehrmonatigem slimstat-Betrieb).
Tante google meinte, dass dieses Problem bekannt ist und gab mir folgenden Link zur Abhilfe: http://wettone.com/weblog/2006/04/20/reducing-size.
Da geht es um das Tauschen der multiple-field index-Dateien gegen solche mit single-field-Indexierung.
Leider ist der Tip des Entwicklers von 2006. Hat jemand hier im Forum
a) ähnliche Erfahrungen mit der DB-"Aufblähung"
b) einen aktuelleren Tip zur Reduzieruzng der DB-Größe?
MfG
Bernd E.
Hi,
momentan scheint sich die Mehrheit damit zu behelfen, den Grundpreis in den Artikeltitel einzubauen: Beispiel G-Produktsuche.
Keine Ahnung ob das abmahnsicher ist. Der G-Preis müsste laut PangV + BGH in unmittelbarer Nähe des Endpreises stehen.
Der Trick mit dem Umfunktionieren d. VPE im normalen Shop:auf die mir bekannten Templates beim cseo 111+ angewandt, sehe ich die Nähe zum Endpreis nur in der Detailansicht gewährleistet, wobei man den String "VPE" noch in "Grundpreis" ändern sollte.
Bei der Artikelliste wird in meinem Template gar kein "VPE" angezeigt, so dass man hier und wahrscheinlich auch an anderen Stellen (Suchergebnisse pp) nachbessern müsste oder sich halt für die Aufnahme in den Titel entscheidet.
Da mir gestern zu Ohren gekommen ist, dass Kunden von uns wegen fehlender Grundpreisangabe abgemahnt wurden, habe ich diese Angaben im Shop vorläufig in die Kurzbeschreibung (wegen d. Artikellisten) und in die Langbeschreibung reingepackt.
Nach einer sauberen und rechtssicheren Lösung suche ich aber auch noch.
Gruß
Bernd E.
PS: hier wurde auch in den google groups über das Thema diskutiert: Link siehe hier
Hallo,
die Sache mit der header.php finde ich interessant!
Soeben stellte sich heraus, dass der Shopbetreiber zwar inzwischen scheinbar wirksame Vorkehrungen gegen die Benutzung des ihm mitgeteilten Links getroffen hat, dafür aber weiterhin die robots.txt (...die xtc-standard-datei...) im Shop-Unterverzeichnis belassen hat. Das Root-Verzeichnis seiner Site scheint überhaupt keine robots.txt zu enthalten.
Soweit mit bekannt ist, wird von den SEs nur in der Root nach der robots.txt gesucht un nicht in irgendwelchen Verzeichnissen.
Gruß
Bernd E.
Komische Sache:
bei der google-Suche nach einem bestimmten XTC-Problem bin ich auf einen Link gestoßen, der folgenden Aufbau hatte (->Domainname wurde mit Rücksicht auf den inzwischen von mir informierten Shop-Betreiber entfernt):
http://www.irgendeine-domain.de/xtcommerce/adm…3722f241b97df30
Nochmal den wichtigen Teil als Text: ....xtcommerce/admin/categories.php?sorting=stock&cPath=0_3&&XTCsid=b7a852580f36854af3722f241b97df30....
Sobald man auf den Eintrag in den Suchergebnissen klickte, gelangte man ohne Probleme in den Adminbereich des Shops und hätte dort alle Kundendaten einsehen sowie alle Daten ändern können.
(Über das Frontend des Shops funktionierte der Zugang nur mit E-Mail-Adresse + Kennwort.)
Kann soetwas auch mit den cseo-Shops passieren und wie kann man sich gegen derartige Dinge wirksam absichern???
Gruß
Bernd E.
PS:
hier noch die "Session-Einstellungen" des Shops (könnte da der "Hund begraben" sein?):
Session Speicherort /tmp
Cookie Benutzung bevorzugen False
Checken der SSL Session ID False
Checken des User Browsers False
Checken der IP Adresse False
Session erneuern False
...und täglich grüßt das Murmeltier...
bei einer von 2 eigentlich bis auf die Datenbank identischen Shopinstallationen (cseo111+) habe ich im Backend bei "Gutscheine versandt" fast jeden Tag seit der Aktivierung des Gutscheinmoduls am 18.12.2009 bis heute ein oder mehrere Einträge über angebliche Gutschein-E-Mails mit dem Absender Admin:
--------------------------------------------------------------------------
Absender Gutscheinwert Gutschein Code Versanddatum
Admin 0,00EUR 18.12.2009
bzw.:
Absender Nr.: 0
Betrag versandt: 0,00EUR
Datum: 18.12.2009
Gutschein Code:
eMail Adresse:
Nicht eingelöst
---------------------------------------------------------------------------
Mir ist das vor kurzem anläßlich einer Gutscheinaktion meiner Frau erstmalig aufgefallen. Die normalen Funktionen des Gutscheinmoduls funktionieren und es gibt in der o.a. Liste auch "echte" Einträge.
Hat einer so etwas schon mal selbst festgestellt und herausbekommen, wo der Fehler liegen könnte?
Gruß
Bernd
Hallo zusammen,
beiliegende Kundininfo bekamen wir gestern von "all-inkl" . Ich habe in den Quelltexten von cseo111+ zunächst nach dem entsprechenden String des Funktionsaufrufes " PASSWORD(" gesucht und nichts gefunden.
Danach habe ich mich an den Kundenservice gewandt, der mich an den Hersteller meines "Shop-Scripts" verwies.
Deshalb meine Frage heute im Forum:
stellt das, was nachstehend betr. "notwendige Deaktivierung der MySQL-Option old-passwords" mitgeteilt wird, für cseo111+-User Anlass für irgendeine Änderung der aktuellen Scripte dar?
Gruß
Bernd E.
> notwendige Deaktivierung der MySQL-Option old-passwords
>
>
> Sehr geehrte all-inkl.com - Kundin,
> Sehr geehrter all-inkl.com - Kunde,
>
> durch die Einführung von php5.3 auf den Webservern und aufgrund von
> zunehmenden Inkompatibilitäten mit externer Software vieler Kunden
> ist es zwingend notwendig, die Option old-passwords nach und nach auf
> unseren Webhosting Servern abzuschalten. Über den genauen Zeitpunkt
> der Deaktivierung informieren wir Sie vorab noch einmal rechtzeitig per
> E-Mail.
>
> Für Sie relevant ist diese Änderung nur in folgenden Fällen:
>
> 1) Sollten Sie MySQL-Abfragen einsetzen, die eine Authentifizierung
> über die MySQL-Funktion PASSWORD() realisieren, so verwenden Sie bitte
> stattdessen die Funktion OLD_PASSWORD(), konvertieren die Passwörter
> in das neue, sicherere Format oder verwenden Sie eine alternative
> Hashmethode zum Verschlüsseln sensibler Daten. Die Mehrheit der im
> Internet verwendeten Scripte sind an diese Methode nicht gebunden, so
> dass es nur in den seltensten Fällen zu Problemen kommt.
>
> 2) Falls Sie lokale Software mit eigenem MySQL Client in der Version
> 3.23 oder 4.0 zur Verbindung zur Datenbank verwenden, so aktualisieren
> Sie diese bitte auf eine MySQL Client Version von mindestens 4.1.
>
> Eine evtl. notwendige Anpassung Ihrer Software sollten Sie bereits
> jetzt durchführen.
>
Danke für die Rückmeldungen,
ich habe mich vor Urzeiten nur mit Clipper-Datenbanken herumgeschlagen und sehe, dass mir betr. MySql ein paar Grundlagen fehlen, da zwischen den beiden Systemen wohl doch Welten liegen.
Um einwenig aufzuholen, habe ich mir jetzt entspr. Literatur besorgt: PHP 5.3 & MySQL 5.1: Grundlagen, Programmiertechniken, Beispiele
Gruß
Bernd E.
Bedank
Ja, so haben wir das schon bei einigen Kunden umgesetzt und funzt prima, vor allem bei großen Datenmengen bringt das enorm viel.
Aber, ich habe noch eine SQL Optimierung als Anhand hier, die bringt auch noch einmal einen Turbo! Habe gerade einen Shop mit 700.000 Produkten optimiert unter anderem damit. VORHER aber Backup vom Shop, Einsatz auf eigenes Risiko! Habe es mehrfach schon eingesetzt und geht.
Hi,
werden die zusätzlichen Index-Dateien in "jeder normalen Lebenslage", sprich: auch bei allen Aktualisierungen der Datenbank (Löschen, einfügen pp) "automatisch&fehlerfrei" immer mit auf den neuesten Stand gebracht oder muss man dazu in die Quelltexte eingreifen??? Wann ist eine Re-indizierung der Datenbank sinnvoll? Gibt es bei mysql eine automatische Prüfung auf Indexfehler?
Gruß
Bernd E.
...habe leider auch noch keine Lösung.
Gruß
Bernd E.
Durch den Ausschluss der englischen Seiten in der robot.txt, verhinderst du zwar, dass die englischen Seiten indexiert werden aber wenn ein User vom (englischsprachigen) Ausland auf deine Seite kommt, bekommt er ja trotzdem die englischen Seiten angezeigt, die ja jetzt noch leer sind...
Hast du dazu eine Lösung.
Grüße
Whyatt
Der Link auf die englischsprachigen Seiten wurde von der Startseite des Shops natürlich entfernt. Da nix indexiert wurde, sind draussen eigentlich auch keine Links auf andere Art in Umlauf gekommen.
Aber Du hast natürlich recht (Vielen Dank für die Erinnerung!) und der auf Englisch laufende Browser krallt sich in der Tat die entsprechenden "leeren" Artikelseiten. Das kann man nicht nur vom Ausland her sondern selbstverständlich auch von hier aus mit z.B. einem Firefox-browser testen, der bei den Einstellungen für die bevorzugte Sprachdarstellung auf Englisch umgestellt wurde.
Ich mach mich heute mal auf die Suche (hier im Forum und im I-net), ob es da neben dem Hinweis von Daniel noch etwas Brauchbares gibt.
Aktualisierung (14.44Uhr): bin wohl im I-Net fündig geworden (verzichte aber vorläufig auf Verlinkung). Sinngemäß hieß es da:
die Browsersprache wird in der includes/application_top.php ermittelt. Falls im Admin Deutsch als Standard definiert wurde und der Shop auch nur so starten soll, folgende Änderung durchführen:
...suche:
if (!isset ($_GET['language'])) $lng->get_browser_language();...ersetze mit:
if (!isset ($_GET['language']))
$lng->catalog_languages[DEFAULT_LANGUAGE];Jetzt startet der Shop in der Standardshopsprache, was ich soben mit Erfolg getestet habe.
Gruß
Bernd E.
Wenn Du nur die findest, kannst Du sie genauso behandeln, wie hier für die Fundstelle mit der etwas abweichenden Schreibweise empfohlen wurde.
Gruß
Bernd E.
(war bei mir auch so!)
Bislang hat der Ausschluß in allen Versionen der empfohlenen robots.txt f. xtc gestanden - S. auch die bekannten online-Handbücher für XTC (Version 2.10 - Seite 124 ff).
Wenn (ohne die heutige Verbesserung durch die canonical-url) früher bei den normalen Shops jedesmal eine Seite mit einer anderen Session-ID indexiert wurde, hatten so manche 70 Produkte-Shops bestimmt mal ganz stolz über 2000 Seiten im Index vorzuweisen. Da machte das Sperren bestimmt Sinn.
Ansonsten liegst Du wohl mit der Annahme richtig, dass heute wenigstens noch etwas Systemleistung eingespart wird.
Gruß
Bernd
Vielen Dank!!!
Endlich kann man das Guthaben und die Einlösemöglichkeit nicht mehr übersehen!
...nun noch schnell Euren Generator eingebaut, den auch noch testen und dann kann es im Echtbetrieb losgehen.
Gruß
Bernd
Wozu sind die hier genau (Z. 1 - 3)? Verstehe ich das richtig, dass er die sessionID und die gesamte englische sprache bei dir beim indexieren weglässt?
So isses.
Die Englischseiten muss ich erst noch bearbeiten (übersetzen, ergänzen) bevor ich die sichtbar online schalten und indexieren lassen kann.
Das wird dauern. Was die sessionID angeht, soll es ja schon mal Suchmaschinen gegeben haben, die so taten, als würden Sie einkaufen - bei mir nicht. LOL!
Gruß
Bernd
PS: ...da ich keiner Suchmaschine über den Weg traue, prüfe ich hin und wieder das Ergebnis der Indexierung auch mal auf "Seitenebene", ob ich wieder was finde, was nicht reingehört.
...ich habe heute gesehen, dass auch jemand anderes so etwas schon gemacht hat (bei demjenigen allerdings mit einer Komplettveränderung des gesamten Rabattkupon - u. Gutscheinsystems).
Mir wäre es lieber, die Lösung käme von Euch, weil wir dann vermutlich alle und auch bei künftigen Versionen davon Nutzen haben können.
Vermutlich funktioniert auch der bei Euch gekaufte Gutscheingenerator nur mit Eurer modifizierten Lösung.
Deshalb halte ich meine Interessenbekundung (Jaaa! Haaaben!) aufrecht.:)
Gruß
Bernd E.
PS: ...wenn ich die Änderungen heute noch einbauen könnte, wäre das super, damit wir nach dem tagelangen Rumprobieren endlich mit dem Rabatt/Gutscheinsystem online gehen können.