Hallo Jonas,
auch ich bin gerade dabei, mit indexed search und crawler eine vernünftige Suchfunktionalität in eine Website zu integrieren.
Die Ergebnisse, die ich dabei erhalte, sind nicht besonders zufriedenstellend. Die Doku zu beiden Extensions schweigt sich m. E. zu wichtigen Punkten der Funktionalität beider Partner und zum Gesamtkonzept der Suche aus, so dass man auf viel eigenes Probieren angewiesen ist.
Vielleicht schaffen wir es, mit vereinter Forumskraft, über Deinen Beitrag etwas mehr Licht in die Sache zu bringen.
Zuerst einige Anmerkungen zu Deiner Konfiguration des crawlers per TSconfig.
# crawler für nicht angemeldete User
tx_crawler.crawlerCfg.paramSets {
content = &L=[|_TABLE:pages_language_overlay;_FIELD:sys_language_uid]
content.procInstrFilter = tx_indexedsearch_reindex, tx_indexedsearch_crawler
content.baseUrl = http://www.deineDomain.net/
}
# crawler für User der Gruppe 1
tx_crawler.crawlerCfg.paramSets {
gruppe1 < tx_crawler.crawlerCfg.paramSets.content
gruppe1.userGroups = 1
}
Antworten auf Deine Fragen.
Bei der URL-Konfiguration für Mehrsprachigkeit ist eindeutig die zweite Version die bessere.
content = &L=[0-3]
oder
content = &L=[|_TABLE:pages_language_overlay;_FIELD:sys_language_uid]
&L=[0-3] arbeitet nach dem Gießkannenprinzip und legt für jede Seite und jede Sprache einen Url-Aufruf an. &L=[|_TABLE:pages_language_overlay;_FIELD:sys_language_uid] arbeitet dagegen intelligent und setzt nur die GET-Variable L auf den Seiten, die tatsächlich auch übersetzt sind (_TABLE:pages_language_overlay) und zwar nur für die Sprachen, die auch vorhanden sind (_FIELD:sys_language_uid). Wichtig die Leeroption [ |]. Sie veranlasst den Crawler, einen Aufruf ohne L für die Standardsprache zu generieren.
Was die Processing Instructions angeht, so dienen sie m. E. dazu, dem Crawler mitzuteilen, für welche Extension der TSconfig-Block gelten soll. Mit
content.procInstrFilter = tx_indexedsearch_reindex, tx_indexedsearch_crawler
würdest Du also sagen, dass der Crawler diese Definitionen neben indexed search auch für seine Arbeit einsetzen soll. Der Crawler ist aber nur der Dienstleister und braucht keinerlei URL-Abfragen für seine Arbeit.
Wäre das anders, müsste der Crawler im BE => Info => Site Crawler bei Einstellung "Srart Crawling" bei Processing Instructions wie indexed search auftauchen, was er ja nicht tut.
Jetzt einige Fragen zu Deinen Überlegungen beim Schreiben des oberen TSconfig und zu Deinen Erfahrungen mit der oben angegebenen Konfiguration.
Deine Aufteilung der URL-Konfiguration in content und gruppe1 hat wohl den Sinn, unterschiedliche Abfragen für jede Seite mit und ohne Zugriffsbeschränkung über FE-User Gruppen zu generieren. Dies ergibt auch auf den ersten Blick einen Sinn, denn so findet der Crawler sowohl die offenen wie die zugriffsbeschränkten Seiten.
Ich habe bei meinen Tests aber mal versuchsweise die Gruppeneinbeziehung in die Definitionen für die Mehrsprachigkeit gepackt (content.userGroups = 0,1,2,3,4). Der Crawler hat bei mir damit auch alle geschützten Seiten indiziert. Die FE-User-Geschichte taucht auch nicht in den GET-Parametern auf. Der Crawler scheint also keine eigenen URL-Abfragen zu brauchen, um die Zugriffsrechte zu verarbeiten. Ist diese Teilung auf Deinen eigenen Überlegungen gewachsen oder was hat Dich zu dieser Teilung veranlasst?
Übrigens, relevant ist die Entscheidung dieser Frage deshalb, weil man mit einem eigenen Key bei großen Websites die Crawler-Warteschlange mit eine großen Packung unnötiger Abfragen füttern würde.
Funktioniert bei Dir diese Konfiguration mit den FE-Usergroups überhaupt wunschgemäß? Ich bekomme nämlich meine Zugriffsbeschränkung über FE-User Gruppen nicht so hin, dass die Suche hinterher bei einem angemeldeten User fehlerfrei funktioniert.
Zwar indiziert der Crawler die zugangsbeschränkten Seiten. Und melde ich mich mit einem FE-User an und starte die Suche, bekomme ich eine passende Trefferliste (offene und geschützte Seiten). Die Vorschau der Treffer moniert jedoch:
"Hinweis: Der Inhalt dieser Seite entspricht nicht exakt der Suche. Die Seitenvorschau wird nicht angezeigt."
Besuche ich die Seite dann angemeldet (Indizierung beim Cachen), wird eine richtig zugeordnete Vorschau erstellt.
Da ich mehrere Gruppen habe, versuchte ich die userGroups-Eigenschaft in einem einzigen Block (gruppe1.userGroups = 1,2,3,4) und wie Du in jeweils eigenen Blöcken (gruppe1.userGroups = 1, gruppe2.userGroups = 2)unterzubringen. Auch die oben genannte Variante (Zugriffsrechte und Mehrsprachigkeit zusammen) zeigte dieses Verhalten. Das Endergebnis bliebt immer wie oben beschreiben.
Tritt bei Dir dieses Problem auch auf? Hättest Du eine Ahnung, was der Crawlerkonfiguration fehlt? (Scheint ja nicht das Problem der indexed search zu sein, denn dann dürfte die Indizierung beim Cachen auch nicht funktionieren)
So, ich denke für eine erste Antwort soll es jetzt reichen.
Gruß
kanticus