Fix für PS 1.6.1.x - Suche mit mehreren Worten - ODER Verknüpfung statt UND

[Scully]

Aus dem englischen Forum habe ich verschiedentlich die Beschwerden über die Suchlogik seit PS 1.6. gelesen. Konkret werden Suchbegriffe, welche aus mehreren Worten bestehen mit ODER anstelle mit UND verknüpft.

 

Vielen Shopbetreibern ist diese Suchstrategie ein Dorn im Auge. Natürlich: Fast immer werden mit der neuen Suche mehr Resultate produziert und auch viel weniger "nicht gefunden" Meldungene angezeigt. Dafür werden im Gegenzug eine Menge von Artikeln angezeigt, auf welche nur ein Suchwort zutreffend ist.

 

Ich habe dafür einen Fix bereitgestellt, welche auf dem Stand von PS 1.6.1.15 basiert, jedoch mehrere Worte wieder per UND - Bedingung verknüpft. Link zum Download:

 

PrestaShop Suche, fix für V1.6.1.x

 

Vorher eine Sicherungskopie von Search.php machen oder das ganze gleich im /override installieren.

Edited August 25, 2017 by Scully (see edit history)

[Claudiocool]

Kannst du mal die Änderungen beschreiben? Ich würde das gerne in meinem 1.6.1.7 auch fixen, weil das oft kritisiert wurd, dass da eine gewisse Logik zu fehlen scheint

[Scully]

Claudio,

 

Vielleicht wartest Du noch einen Moment zu mit dem Download. Ich sehe gerade, dass die PrestaShop Entwickler da noch einiges mehr verbockt haben. Das führt u.a. dazu, dass gewisse Indexe beim Löschen oder Neuanlagen der Produkte kaputt gehen. Ich arbeite daran. Ganz nüchtern.

Auf eine detaillierte Beschreibung wirst Du aber verzichten müssen, es wären dann doch einige Stellen im Argen.

 

Es wird am Ende aber sicher eine feine Sache geben

 

Herzlich, Scully

Edited August 25, 2017 by Scully (see edit history)

[Claudiocool]

Okay, ich hab mal reingschaut, da war der Distinct mit drin und eine foreach-Schleife etwas umgebaut, soweit ich sehe, habe grad nur wenig Zeit, weil da ein paar Leute brav das Ende meines Urlaubs abgewartet hatten

[Scully]

Ich habe grad ein Update hochgeladen, einmal für Search.php und einmal für Product.php. Das erste "repariert" die falsche Suche mit ODER - Bedingungen. Bei Product hat man sich den Unsinn geleistet, den Index für alle Produkte mit semselben Keyword zu löschen, wenn man nur ein Produkt löschen will.

 

Löschte man also ein Produkt mit Keyword Kühlschrank, dann waren alle Kühlschränke weg. Das will so niemand. Beide Changes laufen unabhängig voneinander. Beides bitte in das /override Verzeichnis kopieren.

 

@ Claudio: Code lesen und Du wirst klüger. Der Fehler in der Suche lag NICHT am SQL Query. Kannst ja das bei Dir mal testhalber einspielen und berichten. Und immer vorher Backup der Files anlegen. Toi toi toi.

Edited August 25, 2017 by Scully (see edit history)

[Claudiocool]

Oha..... Ich hab das ja jetzt noch nie probiert.... Will heissen, ich lösche jetzt einen Sensor, die haben alle das Keyword "Sensor" oder z.B. "Schrader" als Marke, dann löscht der alles, wo er diese Keywords findet? Dieses Verhalten ist mir in der 1.6.1.7 nie aufgefallen...

 

Ich hab jetzt grad leider keinen Serverzugriff (Passwort liegt zuhause rum, ich habe mir den Luxus eines guten 18-stelligen Passwortes gegönnt, welches ich aber nicht auswendig weiss), sonst würde ich jetzt mal ein Backup machen und das mal probieren.

[Scully]

Genau dieses Verhalten haben wir heute erst entdeckt. Nicht früher, weil wir alle Indexe mindestens 2x täglich komplett neu aufbauen, was den Fehler bei Löschung dann wieder korrigiert.

[Claudiocool]

Ich dachte, es löscht die Artikel selbst.... du meinstest aber nur die Suchindizes?

 

Das wäre aber auch kein Beinbruch dann, weil die bei mir via Cronjob 2x täglich neu aufgebaut werden.

[Scully]

Nur die Indizes!

[Claudiocool]

Okay, dann passt es ja, weil ich das heute nacht noch getestet hatte und da mit dem GAU gerechnet hatte

[Scully]

Nun ja, wenn die Produkte gelöscht wären, wäre es natürlich noch blöder. Aber ich finde das falsche Löschen der Indizes auch schon eine ziemlich üble Sache.

 

Und warum löschte man falsch?

Weil man in der heldenhaften SQL-Abteilung in Paris wiedermal einen DELETE mit Joins machte, damit man mehrere Löschungen in einem einzigen Statement reingepackt bekommt. Erfahrungsgemäss geht solches oft in die Hose - so auch hier.

 

Und - längst nicht jeder Shop baut seine Indizes täglich neu auf. Ich will gar nicht wissen, wiviele Shops es gibt, bei welchen der letzten Index-Neuaufbau Monate her ist. Oder gar nicht wissen, dass es diese Funktion gibt.

Edited August 27, 2017 by Scully (see edit history)

[Scully]

Claudio - wie wäre es denn nun mit einem kleinen Test - vorerst von Search.php ? Montag ist doch ein guter Testtag.

[Claudiocool]

Ich werde das heute abend mal versuchen, im Moment ist der Kalender noch zu voll, ich kriege meine 30-Stunden-Tage gerade mal so unter

 

Gestern war erstmal die Sofortüberweisung dran, die war jetzt wichtiger, weil da Spielräume drin waren, die den Bestellverlauf sabotieren konnten, wenn der Kunde sich nicht aktiv in den Shop zurückbegab.

[Scully]

Verstanden! Ich habe Deinen Bericht im anderen Thread schon gelesen. Ist mir schleierhaft, wie mal ein Modul mit einer solchen Option ausstattet, bei welcher die Bestellung dann nicht bis zu Ende abgewickelt wird. Hat evtl. auch allgemein mit kompliziertem EU-Recht zu tun, dass das so "sein muss".

[Claudiocool]

Sodele.....

 

Ich kann leider nur die search.php auf die schnelle einbauen, weil die product.tpl bei mir ein paar kleine kosmetische Änderungen drin hat, die ich dann verliere Betrifft zwar nur Anordnungen der Eingabefelder meiner Artikel, aber das war ein Kampf, weil die ganze Sache von Haus aus etwas "bescheiden" umgesetzt ist. Ich habe zwar eine relativ unveränderte product.php (seit dem Serverumzug, bin aber noch nicht sicher, ob da auf dem alten Server noch was gefixt wurde),

das muss ich erstmal prüfen, wenn ich sie gegen eine jungfräuliche Version vergleiche.

 

Manche Dinge lassen sich mittels Hooks ändern, bei anderen Dingen muss man direkt in den Code, das ist nicht sehr konsequent gemacht worden

 

Jetzt hab ich aber gerade ein anderes Projekt, mein Jüngster hat gestern das Waschbecken im Bad zerstört, also ist heute Bau angesagt

Edited September 2, 2017 by Claudiocool (see edit history)