bei einer Suche wird die Artikelnummer nur gefunden wenn diese im “Vater-Artikel” steht.
Bei Artikeln mit Varianten ist dies ja meist nicht der Fall. Wie kann der Artikel trotzdem bei einer Suche nach der ArtNr. gefunden werden?
bei einer Suche wird die Artikelnummer nur gefunden wenn diese im “Vater-Artikel” steht.
Bei Artikeln mit Varianten ist dies ja meist nicht der Fall. Wie kann der Artikel trotzdem bei einer Suche nach der ArtNr. gefunden werden?
Hallo,
die Variantensuche ist aus Performancegründen nicht per default eingebaut. Es gibt hier im Forum eine Anleitung oder gar ein Modul, das genau das tut, was Du willst. Such bitte mal nach “Varianten” und “Suche”.
Gruß
Das Ändern der Zeile 220 in oxsearch.php habe ich durchgeführt.
Danke für den Hinweis.
Jetzt muss nur in der oxarticles noch das feld oxissearch der Varianten suchbar sein, habe ich gelesen. Reicht es dazu über die folgenden SQL- Anweisung alle Werte auf 1 zu setzen?
UPDATE `oxarticles` SET `OXISSEARCH`= 1;
oder muss ich erst herausfinden ob es eine Variante ist?
Hallo,
wenn alle Artikel gefunden werden sollen, müsste in der OXISSEARCH überall eine 1 stehen. Am besten probierst Du vorher mal in Deiner Testumgebung.
Gruß
hallo Marco,
in der Testumgebung hats funktioniert. Der Artikel wird merkwürdigerweise zwar zweimal gefunden, aber es ist der Richtige (eigentlich Einzige).
Dann werd ich jetzt mal die Orginal DB bearbeiten.
Danke
Das Leben kann so einfach sein
PHP-Code:
UPDATE `oxarticles` SET `OXISSEARCH`= 1;
Hallo,
wir nutzen OXID CE 4.8.1 und können die Varianten eines Artikel auch nicht suchen.
In der Datenbank ist bei den betreffenden Artikeln in OXISSEARCH = 1, die Abänderung der oxsearch.php (lt. https://bugs.oxid-esales.com/view.php?id=1149) ist auch nicht möglich da sich die Datei im Laufe der Zeit wohl geändert hat, genauso wie der Pfad.
In den Grundeinstellungen --> Perform. --> ist ein Häckchen bei “Varianten in Artikellisten laden (z. B. Suchergebnisse, Kategorieansichten). Diese Einstellung verbraucht viel Speicher und kann zu Problemen auf schwachen Servern führen.”
Gibt es eine Möglichkeit die Varianten suchbar zu machen? Die Artikelnr. ist ja unter OXARTNUM eingetragen und auch als Suchfeld in den Grundeinstellungen --> Einstell. --> Suche
Hallo @RePiKa,
aber die Suche im Shop nach den verwendeten Methoden sollte schon noch Ergebnisse bringen, auch wenn der Dateipfad nicht mehr stimmt oder?
Gruß
[QUOTE=RePiKa;140156]
In der Datenbank ist bei den betreffenden Artikeln in OXISSEARCH = 1, die Abänderung der oxsearch.php (lt. https://bugs.oxid-esales.com/view.php?id=1149) ist auch nicht möglich da sich die Datei im Laufe der Zeit wohl geändert hat, genauso wie der Pfad.[/QUOTE]
Das einzige, das sich geändert hat:
Aus
oxparentid is null
wurde
oxparentid = ''
oxSearch ab Z.220 gilt nach wie vor…also einfach folgendes schreiben:
$sSelect .= $oArticle->getSqlActiveSnippet();
//$sSelect .= " and {$sArticleTable}.oxparentid = '' and {$sArticleTable}.oxissearch = 1 "; <-org.
$sSelect .= " and {$sArticleTable}.oxissearch = 1 ";
@Marco Steinhaeuser: Die Datei hab ich auch gefunden, aber wusste sie nicht abzuändern… bin nicht der große Programmierer
Aber nun funktioniert es, vielen Dank foxido.de!!!
Wird sich da mal was bewegen? Ich ändere dieses bei unseren Kunde nach jedem Update … das nervt echt!
Es ist nicht default. Lege die Funktion mit der einen (1) geänderten Zeile als Modul ab und mach es damit updatefähig.
nicht mal das, $sSelect wird als string zurückgegeben. Eifnach den Parameter rausnehmen und gut ist.
Wenn er die Datei bei seinen Updates überschreibt, bringt ihm das eigentlich nix. Oder habe ich was überlesen?
wir reden nur bisschen an einander vorbei.
die vollständige search-query kommt als string aus der Funktion _getSearchSelect(), (oder so)
einfach ein Modul machen mit
function _getSearchSelect() {
return str_replace ( "oxparentid" , "oxid" ,parent::_getSearchSelect() );
}
Hallo liebe Programmierer Jungs und Mädels… ^^
die Frage stand heute kann ich aber wieder nur weitergeben, da es immer noch nicht möglich ist…
Ich habe die Datei auch gefunden, aber dort:
application/modules/oxsearch.php
Und wenn ich es das nach dem Bug Fix ändere, dann springt er nach der suche in den Offline Modus…
Im Error Log steht folgendes drin:
xConnectionException-oxException (time: 2014-10-19 21:45:44): [1054]: mysql:EXECUTE error: [1054: Unknown column ‘oxarticles.oxissearch’ in ‘where clause’] in EXECUTE with parameters select oxv_oxarticles_de
.oxid
, oxv_oxarticles_de
.oxparentid
, oxv_oxarticles_de
.oxvarstock
, oxv_oxarticles_de
.oxvarcount
, oxv_oxarticles_de
.oxstock
, oxv_oxarticles_de
.oxstockflag
, oxv_oxarticles_de
.oxshopid
, oxv_oxarticles_de
.oxtitle
, oxv_oxarticles_de
.oxvarselect
, oxv_oxarticles_de
.oxthumb
, oxv_oxarticles_de
.oxpic1
, oxv_oxarticles_de
.oxtprice
, oxv_oxarticles_de
.oxvat
, oxv_oxarticles_de
.oxpricea
, oxv_oxarticles_de
.oxskipdiscounts
, oxv_oxarticles_de
.oxunitquantity
, oxv_oxarticles_de
.oxunitname
, oxv_oxarticles_de
.oxprice
, oxv_oxarticles_de
.oxvarname
, oxv_oxarticles_de.oxtimestamp from oxv_oxarticles_de LEFT JOIN oxv_oxartextends_de ON oxv_oxarticles_de.oxid=oxv_oxartextends_de.oxid where ( oxv_oxarticles_de.oxactive = 1 and ( oxv_oxarticles_de.oxstockflag != 2 or ( oxv_oxarticles_de.oxstock + oxv_oxarticles_de.oxvarstock ) > 0 ) and IF( oxv_oxarticles_de.oxvarcount = 0, 1, ( select 1 from oxv_oxarticles_de as art where art.oxparentid=oxv_oxarticles_de.oxid and ( art.oxactive = 1 ) and ( art.oxstockflag != 2 or art.oxstock > 0 ) limit 1 ) ) ) and oxarticles.oxissearch = 1 and ( ( oxv_oxarticles_de.oxtitle like ‘%9783981170187%’ or oxv_oxarticles_de.oxshortdesc like ‘%9783981170187%’ or oxv_oxarticles_de.oxsearchkeys like ‘%9783981170187%’ or oxv_oxarticles_de.oxartnum like ‘%9783981170187%’ or oxv_oxartextends_de.oxtags like ‘%9783981170187%’ ) ) LIMIT 0, 50, for user oxe
Die Artikelnummer ist direkt von einem Variantenartikel… Den findet er über die normale Suche nicht… Hat vielleicht jemand auch Erfahrung mit dem Flexi Search, ich kann dieses Modul leider nicht testen, da ich keine testlizenz bekomme…
Vielen Lieben Dank…
Hallo,
[QUOTE=individuellz;151391]
die Frage stand heute kann ich aber wieder nur weitergeben, da es immer noch nicht möglich ist… [/QUOTE]
Richtig. Es ist auch nicht geplant, das per default möglich zu machen. Denn damit könnte man sich in gewissen Konstellationen die Performance abartig herunter reissen.
[QUOTE=individuellz;151391]
Und wenn ich es das nach dem Bug Fix ändere, dann springt er nach der suche in den Offline Modus…
[/QUOTE]
Es gibt keinen Bugfix, denn sonst wäre das im Standard implementiert. Es gibt maximal einen Workaround, der zu einem bestimmten Zeitpunkt verfasst wurde.
Ein einfaches Modul zu dem Thema wäre vielleicht mal keine schlechte Idee.
Gruß
is doch fertig mal im exchange suchen
Schau dir mal diese Ext an: http://www.druteika.lt/#diamond_search_for_oxid_eshop
Flutscht auch mit der 4.9er nachdem die Sprachdateien verschoben und eine Datei bearbeitet wurde. Der Dev hat einen Patch und in Kürze sollte es auch auf Github verfügbar sein.
Wie Marco schon sagte, wird die Performance anfangs (bei Neuindexierung) stark leiden. Doch wenn die Erstindexierung abgeschlossen ist, läuft der Shop wieder im grünen Bereich.
Schön wäre, wenn “stopwords” definiert werden könnten, dann würden die zugehörigen Tabellen in der DB nicht so dick werden.
Gruß
Ich habe für einen Kunden gerade genau so ein Modul geschrieben. Es macht eigentlich nicht mehr als die function _getSearchSelect() zu überlagen und dabei den Filter auf die oxparentid=’’ wegzulassen. Ich packe das Modul einfach in den Anhang und hoffe, dass ich dem ein oder anderen damit eine kleine Freude machen kann.