Hallo, ich arbeite gerade an unserer Suche und würde gerne einen Suchmodus nach “Größe” einbauen. Ich übergebe momentan die Größe per $sRequests['sFilter']['size'] an $sSearchResults = $this-\>sSYSTEM-\>sMODULES['sSearch']-\>sStartSearch($sRequests); Es werden mir jedoch immer alle Artikel angezeigt, so als würde die Größe nicht beachtet werden. Da die Funktion vermutlich in der sSearch.php liegt und diese per Zend codierte wurde habe ich darauf keinen Zugriff.
Hey, wie soll das denn funktionieren? Also wenn du einfach „size“ an die Suche übergibst, kann die ja nicht wissen, das du nach Größe filtern möchtest :)? Habe das noch nicht so ganz verstanden - hast du die Größen als Eigenschaften gepflegt? Hast du die Intelligente Suche lizenziert oder „nur“ die Standard-Suche aktiv? Mehr Informationen wären hilfreich…
HI, die intelligente Suche ist lizensiert. Das es nicht einfach so funktionieren kann ist mir klar. Die Größe steht im Additionaltext Feld der Varianten also in article_details. Da die Funktion nirgends Dokumentiert ist (oder ich zu blind bin es zu finden) suche ich nach einer Erläuterung. Ich kann sie ja nicht selbst einsehen da die Suche codiert ist (Warum eigentlich? Sollte es nicht OpenSource sein?). Gruß und frohe Festtage
Moin, die optionalen Zusatzmodule sind verschlüsselt (Wohingegen der Core komplett offen ist) - sonst könnte dort ja jeder die Lizenzprüfung ausbauen und die Module beliebig kopieren 
Es gibt also primär 2 Möglichkeiten: 1.) Selber seit ihr wahrscheinlich kein Partner, oder? Ansonsten könntest du nämlich auf den Quellcode zugreifen. Also alle Shopware Business & Solution-Partner haben Zugriff auf den Quellcode der Module. 2.) Der elegantere Weg: Du erzeugst aus den Varianten automatisch Filter-Eigenschaften per Script, danach kann ja sowieso per Default selektiert werden. Du legst also zunächst eine neue Filtergruppe mit der Eigenschaft “Größe” an. a.) Dann in der Tabelle s_filter die ID der neuen Eigenschaftsgruppe suchen und notieren b.) Das gleiche machst du für die angelegte Option (Größe) in s_filter_options - in meinem Fall haben beide Einträge die ID 1. c.) Als nächstes machst du ein update auf s_articles um alle Artikel dieser Gruppe zuzuordnen. UPDATE s\_articles SET filtergroupID = ID\_DER\_EIGENSCHAFTSGRUPPE (Bei neuen Artikeln, würdest du die Gruppe direkt in den Stammdaten auswählen / zuweisen) d.) Nun kannst du automatisiert alle Varianten-Bezeichnungen in Filter-Eigenschaften verwandeln: INSERT IGNORE INTO s\_filter\_values (groupID,optionID,articleID,value) (SELECT 1,1,articleID,additionaltext FROM s\_articles\_details WHERE additionaltext != '') Hinweis: Parameter 1 und 2 stehen für groupID und optionID - beide Werte ergeben sich ja in Absatz a. und b. - diese müssen dann also durch die tatsächlichen Ids ersetzt werden e.) Natürlich könnte man die Query auch automatisiert ausführen oder über ein Plugin. Außerdem könnte man mit “On Duplicate” auch das aktualisieren von Varianten-Bezeichnungen umsetzen. f.) Eventuell arbeitest du noch mit einem Zusatzfeld (Attribut) - wo du alle Artikel, die automatisch gefiltert werden sollen, markierst. Zum Beispiel mit attr1 = 1 - dann sähe die Füllquery wie folgt aus: INSERT IGNORE INTO s\_filter\_values (groupID,optionID,articleID,value) (SELECT 1,1,s\_articles\_details.articleID,additionaltext FROM s\_articles\_details, s\_articles\_attributes WHERE additionaltext != '' AND s\_articles\_details.articleID = s\_articles\_attributes.articleID AND s\_articles\_attributes.attr1 = '1') Also so würde ich es lösen - das kommt a.) ohne Programmierung aus und b.) ist das komplett Updatefähig.
P.s. hatte ich oben noch nicht erwähnt - die Suche unterstützt ja das Filtern nach Eigenschaft per Default - auch kann man diese Filterung über direkte URL-Aufrufe auslösen. Auf diesem Weg lassen sich theoretisch also auch Mehrdimensionale Varianten und andere Konstellationen automatisch in Eigenschaften transferieren, die dadurch nicht zusätzlich gepflegt werden müssen. Das bietet sich nun ggf. auch für andere Konstellationen an, die so nur mit manueller Pflege der Filter umsetzbar wären! Frohe Weihnacht
Damit ist übrigens auch noch ein anderes Problem im Zusammenhang mit eindimensionalen Varianten obsolet - bisher können diesen ja keine Eigenschaften zugeordnet werden, das funktioniert mit dieser Lösung auch. Alternativ kann man z.B. statt additionaltext auch ein Zusatzfeld (Attribut) abfragen - dann können die Werte im Filter sogar andere Bezeichnungen haben, wie die tatsächlichen Eigenschaftsbezeichnungen.
Vielen Dank, dass ihr euch auch über die Feiertage um eine Antwort bemüht. Ich werde mir deine Antworten nochmal in Ruhe anschauen und sehen ob es für uns sinnvoll ist es so umzusetzen. Vielen Dank und frohe Festtage!
Hallo, ich habe das jetzt so wie oben beschrieben umgesetzt. Es funktioniert auch wunderbar, jedoch ist der Nachteil, dass mir auch Artikel angezeigt werden dessen Größe nicht mehr vorrätig ist. Wie kann ich das ausschliessen?
Habe jetzt alles wieder rückgängig gemacht da diese Lösung unseren Shop einige Tage lahm gelegt hat.
Hey, wie hast du die Lösung denn integriert? Das gibt es ja nun auch als Plugin - welches man per Cronjob z.B. täglich aufrufen kann? Hattest du die Aktualisierung bei jedem Seitenrequest durchgeführt?
Die Lösung an sich passt schon. Das Problem liegt darin, dass wir für jeden Artikel ca. 7 Varianten haben (Größen: L,XL,S,42,34,ect…). Das Ergbnis waren über 20.000 Eigenschaften in der Datenbank die jedes mal abgerufen oder durchsucht worden sind. Somit wurden die Querys irgendwann gelocked und daraufhin wurde der Cache riesengroß was zur Folge hatte, dass der Shop nicht mehr erreichbar war da unter andrem die maximalen Verbindungen zur Datenbank erreicht waren. Das Request wurde bei der Suche und bei jeder Kategorieeinsicht aufgerufen soweit ich mich erinnere ;-).