ich habe ein massives Problem, der Provider eines meiner Kunden hat den Shop des Kundens mit folgender Begründung abgeschaltet:
[I]"Ihr Account erzeugt sehr hohe Serverlast, bis hin zur Beeinträchtigung einzelner Dienste. Verursacht wird dies durch Abfragen Ihrer MySQL Datenbank “oxid-db”.
Problematisch sind:
Searchtags in der Datenbank “oxid-db” mit unzähligen “%5C” !"
[/I]
Betroffen ist hier die Tabelle “oxseo”, hier finden sich unzählige Einträge wie z.b.:
sieht aus, als würden die URLs falsch erzeugt, evtl. durch ein Modul oder eine kaputte Datei? Jedenfalls werden die “&”-Zeichen als entity interpretiert und scheinbar sinnlos aneinander gereiht. Fahr doch mal mit einer oxchkversion über den Shop.
This script is intended to check consistency of your OXID eShop. It collects names of php files and templates, detects their MD5 checksum, connects for each file to OXID’s webservice to determine if it fits this shop version.
It does neither collect nor transmit any license or personal information.
Data to be transmitted to OXID is:
Filename to be checked
MD5 checksum
Version which was detected
Revision which was detected
For more detailed information check out OXID eSales’ Blog.
na ja, dann frag halt den Provider mal, ob das Script rauskommt oder ob er’s mal kurz freischalten kann. Ansonsten spiegel den Shop auf die lokale Büchse und führ den Test dort mal durch. Ich denke, das ist ein essenzieller Test, wenn man nicht irgendwo im Heuhaufen herumstochern möchte
??? versteh ich nicht welches Script muss verher “freigeschaltet” werden???
Ich habe das Script auf meiner lokalen Installation ausgeführt, mit dem selben Erfolg … ?!?
Also: die oxchkversion versucht eine Verbindung zu irgendeinem OXID-Server herzustellen, holt sich dort MD5-hashes ab und vergleicht die mit denen Deiner Dateien. Danach spuckt sie Ergebnisse aus: soundsoviele Dateien geändert, soundsoviele nicht original etc…
Wenn das Script (oxchkversion) nicht bis zum OXID-Server kommt, erhälst Du die o.g. Meldung. Irgendeine Firewalleinstellung verhindert, dass oxchkversion über Port 80 nach draussen greifen kann.
Danke, aber verstehe ich das jetzt richtig? Im ersten Schritt werden die Tags aus den Artikeln gelöscht - hört sich unproblematisch an.
Im zweiten Schritt werden nun die Einträge aus der OXSEO gelöscht … hm, an andere Stelle habe ich gelesen, dass man das auf gar keinen Fall machen soll. Da sonst keine Artikel mehr gefunden werden …
… nochmal zurück zum Vorschlag mit der oxchkversion.php, kann es wirklich sein, dass Dateien geändert wurden, trotzdem dass ein Update gemacht wurde? Kann man dieses Problem nicht vielleicht durch ersetzen der Dateien auf dem Server durch die Original-Dateien (außer tpl natürlich) auch lösen?
[QUOTE=recDesign;107272]… nochmal zurück zum Vorschlag mit der oxchkversion.php, kann es wirklich sein, dass Dateien geändert wurden, trotzdem dass ein Update gemacht wurde? Kann man dieses Problem nicht vielleicht durch ersetzen der Dateien auf dem Server durch die Original-Dateien (außer tpl natürlich) auch lösen?[/QUOTE]
Ja. Gerade bei Updates kann so etwas passieren (Übertragungsfehler etc…). Um herauszubekommen, welche Dateien genau ersetzt werden müssen oder vielleicht gar dran schuld sind, brauchst Du die oxchkversion. Kann ja niemand beurteilen, ob Du nicht vielleicht doch funktionale Änderungen direkt in den Dateien durchgeführt hast
[QUOTE=Marco Steinhaeuser;107279]Moin,
Ja. Gerade bei Updates kann so etwas passieren (Übertragungsfehler etc…). Um herauszubekommen, welche Dateien genau ersetzt werden müssen oder vielleicht gar dran schuld sind, brauchst Du die oxchkversion. Kann ja niemand beurteilen, ob Du nicht vielleicht doch funktionale Änderungen direkt in den Dateien durchgeführt hast
Gruß[/QUOTE]
Änderungen in den core-Dateien habe ich keine vorgenommen … beim Update wirds wohl nicht passiert sein, da das Update ja in der Hoffnung vorgenommen wurde den Fehler auszumerzen (trat vorher schon auf).
Falls ich die oxchkversion.php nicht ans Laufen bekomme, werde ich mal die ganzen Daten auf dem Server ersetzen …
ich hatte nur ein paar Artikel mit &, die ich schnell ersetzen konnte. Auf jeden Fall schneller als eine Lösung zu finden.
Gerade habe ich nochmal mit dem Demoshop und meinem alten Shop die Tags getestet. Mein Ergebnis: Dein Kunde hat einen alten Oxid-Shop kleiner 4.4.8 !!!
Updaten hilft!
Bei einem Oxid-Shop kleiner= 4.4.8 wird aus seinem Suchbegriff mit & ein Tag mit …& Das führt dann zu den von dir beschriebenen Problemen, da das & stets weiter ersetzt wird duch einen Bot oder Crawler.
Bei einem Shop größer 4.5.0 (getestet mit 4.6.4 und 4.7.0.beta) wir aus einem Suchbegriff mit & “nur” ein " amp " (inkl. Leerzeichen) als Tag. Wenn man bei den Tags ein & eingibt ersetzt er es durch ein Leereichen.
Meiner Meinung nach hilft also nur ein entfernen der & in den Suchbegriffen (und Tags) oder ein Updaten.
der Shop ist Version 4.4.8. Ein Update auf 4.5 kommt leider nicht in Frage, da die Temples komplett neu gemacht werden müssten - dafür hat der Kunde im Moment kein Budget. Ein Update ist aber für Anfang kommenden Jahres geplant.
Das “&” habe ich nun aus den Tags gelöscht - hoffen wir mal, dass damit der Spuk zu Ende ist.
Allen nochmal vielen Dank für Eure Hilfe und Tipps
