Suche ungenau / Ergebnisse nicht korrekt

@Moritz Naczenski schrieb:

@Exe schrieb:

Bisher hat sich bei uns noch keiner über die Suche intern beschwert aber habt ihr schon Erfahrung mit der ElasticSearch Suche?

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍ welche Daten laufen in ES rein und werden für die Suche genutzt? Könnte man wie in deinem Pluginbeispiel, die Daten festlegen, was genutzt werden soll? Zum Beispiel würde wir den Hersteller nicht in die Suche aufnehmen. Das könnte ich wie in deinem Plugin recht gut erkennbar ja einfach aus der normalen rausnehmen. Aber würde das dann auch für die ES Suche gelten, die wir sicher später irgendwann einbinden werden?

Elasticsearch hat da eine deutlich abweichende Implementierung: https://github.com/shopware/platform/blob/master/src/Elasticsearch/Framework/AbstractElasticsearchDefinition.php#L83

Soweit ich weiß, gibt es im Index nur zwei Felder um die Indexierung möglichst Schmal zu halten und auch den Index klein zu halten. In diese Felder werden dann aber die Informationen aus den Entitäten reingeschrieben (siehe oben)

Da ich ein paar Stunden daran hing: Das sieht zwar so aus, aber es wird auch in der Community-Version sehr viel mehr in den ES-Index geschrieben - das ist nur nachher nicht mehr so einfach sichtbar:

Wenn man in der ElasticsearchDefinition.php im Mapping das Feld ‚_source‘ löscht / unsetet sieht man auch im ElasticSearch-Index, das alle möglichen Felder mit indexiert werden.

Allerdings durchsucht die Community-Version nur die „gebauten“ Felder fulltext / fulltextBoosted bzw description (https://github.com/shopware/elasticsearch/blob/6.2/Framework/AbstractElasticsearchDefinition.php#L69 https://github.com/shopware/elasticsearch/blob/6.2/Product/ElasticsearchProductDefinition.php#L71) - das ist der Hebel, über den man die eigentliche Suche in Elasticsearch anpassen kann (z.B. über hinzufügen von https://github.com/ongr-io/ElasticsearchDSL/blob/master/src/Query/Joining/NestedQuery.php)

Die Suche im Frontend funktioniert tadellos mit ElasticSearch, auch ohne Plugins.

 

Die Suche im Backend ist eine Katastrophe - deswegen haben wir ein eigenes Backend entwickelt, welches voll funktionsfähig, schneller und besser läuft.

 

Um die Suche im Frontend zu aktivieren muss ElasticSearch (alte Version … warum auch immer) installiert werden.

Danach die Datei .env öffnen und folgenes anlegen/anpassen:

 

 SHOPWARE\_HTTP\_CACHE\_ENABLED=1 SHOPWARE\_HTTP\_DEFAULT\_TTL=7200 SHOPWARE\_ES\_HOSTS="" SHOPWARE\_ES\_ENABLED="0" SHOPWARE\_ES\_INDEXING\_ENABLED="0" SHOPWARE\_ES\_INDEX\_PREFIX="sw" SHOPWARE\_CDN\_STRATEGY\_DEFAULT="id"

Danach noch (per sudo) folgendes in der Shell im doc-root ausführen:

 

sudo -u ./bin/console dal:refresh:index

Cache danach noch löschen mit

sudo -u ./bin/console cache:clear

und es läuft.

 

 

Was mir nicht so ganz einleuchtet ist folgende Problematik: im Backend kann ich problemlos suchen (Vers. 6.3.5.1) mit der Artikel-Nr., aber im Frontend muss ich zwingend mit dem Artikel-Namen suchen, da ich dort mit Art-nr. nur mit viel Glück fündig werde.

Beide „Suchen“ greifen doch auf ein und denselben Datenbestand zurück ?! Warum findet die eine etwas, was die andere absolut nicht findet bzw. nur gelegentlich ?

Gruß BB

es werden (offensichtlich) unterschiedliche Datenquellen für die Suchen verwendet.
Wenn du nach Artikelnummer suchen möchtest, dann gib sie bei den Tags ein. Das hilft.

Moin,

das mit der Artikel-Nr. habe ich bei den Tags und auch bei den Such-Schlagwörtern probiert, jedoch ohne Effekt. :man_shrugging: Meine Kunden nutzen viel die Artikel-Nr. zur Suche… und finden entsprechend wenig bis gar nichts oder häufig das falsche…

Gruß BB

Das ist seltsam.
Artikelnummer bei den Such Schlagwörtern funktioniert eigentlich.
Bei Suche muss ich bei mir bei Ziffern jedoch mindestens 5 Ziffern eingeben, wenn der Suchbegriff mit Buchstaben anfängt, reichen 3
Alles sehr komisch

Muss dabei irgendwas beachtet werden ? Anführungszeichen, Hochkomma etc ? Egal was ich probiert habe, es war nie von Erfolg gekrönt…

Vielleicht liegt es daran das meine Art-Nr. alle 4-Stellig sind ? Aber die Übereinstimmung muss ja nur 2-stellig sein…

Gruß BB

naja, wie ich dir oben geschrieben habe, bei 4-stelliger Artikelnummer geht es bei mir auch nicht.
btw, wie kommst du drauf, dass es nur 2-stellig sein muss?

Wenn ich z.B. die Art-Nr. 7000 eingebe, bekomm ich zwar nicht mal ansatzweise den eigentlich Artikel angezeigt, aber zwei Artikel in denen die 7 und die 0 vorkommen… mehr übereinstimmungen gibt es da nicht.

Bei uns auch, großes Problem mit der Suche…

Eingabe von „Nikon Z 14-24mm“ führt zwar endlich zu einem Ergebnis, aber obwohl der „wichtigste“ Artikel exakt so anfängt, ist er trotzdem nur an 3. Stelle
https://www.imagebanana.com/s/2051/L1SWKq9x.html

Und bei der Eingabe von „Nikon Z 14-24“ erscheint dieser Artikel noch nicht mal auf der ersten Suchseite. Dafür andere, die offensichtlich viel weniger nah dran sind.
https://www.imagebanana.com/s/2051/OqnNHYsW.html

Ich experimentiere nun mit DooFinder, so hat unser Kunde große Probleme damit.

Shopware ist ein so geniales Produkt, aber die Suche könnte etwas Maintenance vertragen!

(P.S. Bilder konnte ich nur verlinken, da als „neuer“ Benutzer das Hochladen von Medien nicht gestattet ist)

Das (mynotes Änderungen an der .env) hat leider gar nicht geholfen. Das ist doch echt peinlich für Shopware. Das allererste, was in Shopware erscheint ist das Suchfeld oben in der Seite. Man könnte meinen, das ist eine zentrale Funktionalität…

Habe auch ein Beispiel:
https://www.holosun.eu/de:
Suche nach he50 findet das HS506
Suche nach he509 findet nichts
HE509T findet wieder zwei andere Produkte
HE509T-RD findet das richtige und noch mehr falsche

@Shopware-Team: Wie wärs denn mit ein paar Unit-Tests für die Suche? Kann gerne genug Testfälle liefern

Nachtrag: Ich habs gefunden. Man muss die “UND”-Suche aktivieren. Anscheinend splittet Shopware den Suchbegriff an der Nummer und findet dann nur Schrott. Mit UND-Verknüpfung kommt es wenigstens halbwegs hin… Kaputt ists immer noch, aber wenigstens nicht völlig unbrauchbar.

Wann war eigentlich jemals eine Oder-Suche sinnvoll? Wenn ich mehr eingebe, will ich doch genauere Ergebnisse, nicht schlechtere. Siehe Google. Was für ein Quatsch und dann (anscheinend) auch noch per default aktiv.

1 „Gefällt mir“

Hallo in die Runde,

ich klinke mich mir auch mal ein, da sich in einem aktuellen SW6-Projekt auch massive Mängel gezeigt haben: In einem Shop für Eisrohstoffe liefert die Suche nach „vegan“ Artikel mit „vanille“ – die eigentlich veganen Produkte fehlen jedoch. Ich kann sogar ein völlig fremdes Produkt, etwa einen Plastiklöffel, in der (falsche) Ergebnisliste zur „vegan“-Suche aufnehmen, indem ich als Such-Schlagwort „vanille“ hinzufüge.

Das ergbit irgendwie alles überhaupt keinen Sinn.
Auch die Umstellung von ODER-Suche auf UND-Suche brachte keinerlei Änderung.

Ich erwarte überhaupt keinen Support für die Community-Version, das ist klar. Aber das ein essentielles Shop-Feature wie die Suche nicht korrekt funktioniert und das Problem, trotz Kenntniss seit mindestens Mitte des letzten Jahres, nicht angegangen wird, ist schon ärgerlich.

1 „Gefällt mir“

@andreherdling dass das nicht angegangen wird ist meiner Meinung nach nicht ärgerlich, sondern eine Unverschämtheit

1 „Gefällt mir“

Das Grundsätzliche Problem an der Sache ist das die Suche die Ergebnisse nicht an Hand der übereinstimmenden Treffer sortiert. Dieser „Bug“ wird schon seit 2,5 Jahren aus dem Weg gegangen. Dort eine Sortierung einzubauen ist sicher kein Ding der Unmöglichkeit für Shopware. :face_with_raised_eyebrow:
Ich gebe hier allen anwesenden Recht, die Suche ist ein unglaublich wichtiger Grundbestandteil eines Shops.
Ich denke das es Shopware wichtiger ist, eher für die Vermittlung von dritt Anbieter-Plugins ordentlich mitzuverdienen, statt die Arbeit selber zu machen. Das ist leider der falsche Weg. Das wird letztendlich auch Shopware die Kunden kosten.

VG

2 „Gefällt mir“

Ich bin gerade auch dabei von SW5 auf SW6 umzusatteln, und bin in weiten Teilen eigentlich fertig. Was die Suche allerdings in SW6 zu Tage fördert ist - schlicht gesagt - unfassbar schlecht, oder besser absolut unbrauchbar. Wie kann man ein Shopsystem mit einer nicht nutzbaren Suche auf den Markt bringen. Warum geht das in SW5 richtig gut, und in SW6 komplett gar nicht?

Gibt es hier inzwischen irgendwelche Lösungsansätze mit den Boardmitteln ohne Drittanbieter Plugin?

Ein Produkt mit dem Namen „STP Black Gold Bulk Pack“ wird in der Suche nicht gefunden, wenn ich nur den Produktnamen als Suchbegriff eingerichtet habe, und mit „stp gold“ suche, egal ob UND oder ODER. Ich bin gerade echt sprachlos…

3 „Gefällt mir“

Ich wärme den Thread auch mal wieder auf.
Zwischenzeitlich hat sich ja doch ein bißchen was bewegt, wobei die grundlegenden Probleme nach wie vor bestehen – jedenfalls im Frontend.

Die Backend-Suche nach Produkten funktioniert meiner Meinung nach mittlerweile echt gut und bringt sogar brauchbare segmentierte Ergebnisse.
Gibt’s das bald irgendwann auch im Frontend @Moritz_Naczenski?

3 „Gefällt mir“

Ich wärme mal weiter auf. Gleiche Thema immer noch in einer 6.4.19.1.

1 „Gefällt mir“

1. Problem:
Suche nach exaktem Artikelnamen führt dazu, dass der Artikel in den Suggestions gar nicht auftaucht und auf der Suchergebnissseite vielleicht auf Seite 2 oder 3 - obwohl exakt der Artikelname eingegeben wurde
2. Problem
Suche nach einem Zusatzfeld, welches die höchste Priorität von allen Suchkriterien erhalten hat. Suche nach exaktem Begriff, welcher im Zusatzfeld steht - Artikel erscheint wie bei Problem 1. nicht einmal in den Such-Suggestions und vielleicht auf Seite 2-3 der Suchergebnisseite
3. Problem
Gewichtung scheint überhaupt nicht zu funktionieren bzw. macht die Gewichtung keinen Sinn, wenn Shopware die einzelnen Wörter eines Suchkriteriums gewichtet und den kompletten Begriff selbst nicht in der Index-Tabelle mit einer noch höheren Gewichtung speichert.
Beispiel:
Artikelname „Mein perfektes Produkt für die Suche“
Wenn hier jetzt die einzelnen Wörter gewichtet werden ohne auch den gesamten Begriff oder Teile zu gewichten und in die Tabelle zu schreiben, kommen natürlich irgendwelche Produkte zurück, die ebenfall „Mein“ oder „perfektes“ als Keyword in der Suchindex-Tabelle haben…
4. Problem
Umstellung der Suche von ODER auf UND Verknüfung führt dazu, dass manche Produkte überhaupt nicht mehr gefunden werden, wenn der komplette Artikelname eingegeben wird.
5. Problem
Artikelnamen wie „1924 - 2012 Mein Produkt / Titelbeispiel“ werden überhaupt nicht gefunden. Weiß nicht, ob die Zeichen „-“ und „/“ dafür sorgen, dass die Suche nicht mehr klar kommt.
In den Suchvorschlägen steht das Produkt noch drin bei Eingabe von „1924“ - wird dann noch „mein“ oder „Produkt“ eingegeben, gibt es auf einmal keine Suchergebnisse mehr

Die Backend-Suche ist 1000x besser als die Frontend-Suche!?

4 „Gefällt mir“

Wir nutzen Shopware 6.5.3.3 und auch bei uns ist das Problem, dass die Suche nach einer Artikelnummer zwar den gewünschten Artikel, aber auch noch 7 weitere Artikel liefert, welche mit der Artikelnummer absolut nichts zu tun haben (auch nicht als Bestandteil einer anderen Produkt-Eigenschaft oder Nummer). Die Suche im Backend funktioniert korrekt. Der Artikel-Stamm wurden vorgestern in den Shop eingespielt - die Artikel scheinen also zumindest schonmal im Such-Index enthalten zu sein sonst wäre vermutlich kein Artikel gefunden worden.

Folgendes ist mir bei meiner Recherche aufgefallen:


1.) Falsches Datum bei „zuletzt erstelltem Such-Index“

Im Adminbereich unter „Einstellungen > Suche“ gibt es den Reiter „Echtzeit-Suche“. Zum Testen hatte ich eben den Such-Index mit Klick auf den entsprechenden Button neu erstellt. Obwohl der Such-Index laut Meldung erfolgreich erstellt wurde, steht hinter dem Button „Zuletzt erstellt: 4.10.2022, 11:01“ - Ich glaube etwa zu diesem Zeitpunkt hatten wir den Shop damals installiert. Die Datums- und Zeit-Angaben sind also falsch.


2.) Seltsame Rangpunktzahl bei „Verkaufskanal-Echtzeitsuche“

Des Weiteren kann man im Adminbereich im oben benannten Reiter eine Echtzeitsuche ausführen und sich dort sogar die Rangpunktzahl für die einzelnen Treffer anzeigen lassen. Das habe ich für meine Suche nach meiner Artikelnummern gemacht. Es werden mir dort die gleichen Treffer geliefert wie im Frontend, d.h. mein eigentlich gesuchter Artikel als erstes und dann noch die 7 falschen Artikel.

Mein korrekter Artikel erhält die Rangpunktzahl 1700. D.h. entsprechend meiner Such-Einstellung vergibt Shopware 1000 Punkte für die identische Produktnummer, addiert dann aber noch 700 Punkte drauf. Woher diese 700 Punkte kommen weiß ich nicht. Für den Produktnamen hatte ich einen Rang von 700 eingestellt, aber der Produktname enthält die Artikelnummer nicht und sie taucht auch sonst nirgendwo in den Produkt-Eigenschaften auf außer im Feld „Produktnummer“.
Die anderen 7 „falschen“ Treffer (bei denen meine gesuchte Artikelnummer NICHT vorkommt - auch nicht als Bestandteil anderer Eigenschaften) haben die Rangpunktzahlen 400, 300 und 100. Diese Werte habe ich allerdings bei KEINER meiner Such-Einstellungen hinterlegt. Für deaktivierte Felder bei der Suche ist der Wert 0 hinterlegt und bei den anderen Feldern habe ich die Werte 1000, 700 und 500 hinterlegt. Es ist rein rechnerisch also gar nicht möglich durch Addition meiner hinterlegten Rangpunkte die Punktzahlen 400/300/100 zu erreichen und daher ist es mir unbegreiflich, wie Shopware auf diese Rangpunktzahl kommt (es sei denn der Algorithmus nutzt hier noch irgendwelche mir unbekannten Faktoren).
Wenn man herausfindet WIE/WO diese Rangpunktzahlen entstehen bzw. berechnet werden, findet man vermutlich auch den Grund für die falsch angezeigten Treffer, denn letztendlich zeigt Shopware vermutlich nur Treffer mit einer Rangpunktzahl > 0 an…

1 „Gefällt mir“