Hallo Jonas,
habe mir inzwischen den Beitrag im Wiki angeschaut. Irgendwelche Hintergrundinfos sind dort leider auch nicht zu finden, die die Sache vom Funktionsprinzip her klären würden. Auch manch eine Einstellung scheint mir fragwürdig.
Die Erläuterung zu den FE-Benutzergruppen konnte ich aber so, wie sie da steht, nachvollziehen.
Habe daraufhin mein TSconfig umgebaut und siehe da, mein Problem hängt genau mit meiner bisher falschen Interpretation der Eigenschaft userGroups.
Die Eigenschaft userGroups innerhalb eines Key-Blocks teilt nach den Ausführungen dort und meinen Tests dem Crawler anscheinend nicht mit, für welche FE-Benutzergruppen diese gelten soll, sondern nennt einen ganz spezifischen beispielhaften Benutzertyp mit bestimmter Gruppenzugehörigkeit, für den der Block wirksam ist. Der Block ist demnach so zu lesen, als ob die durch ihn definierten Aufrufe von einem Benutzer mit den in userGroups definierten Benutzergruppenzugehörigkeiten abgesetzt worden wären.
Hat eine Site also vier FE-Benutzergruppen ( 1,2,3,4) und Benutzer, die ganz bunt diesen vier Gruppen zugeordnet sind, so muss man so viele Key-Blocks anlegen, wie viele Kombinationen von Bentzergruppen bei den Benutzern real vorkommen.
userGroups = 1 (für Benutzertyp, der nur zu 1 dazugehört)
userGroups = 1,2 (für Benutzertyp, der zu 1 und 2 dazugehört)
userGroups = 1,2,3 (für Benutzertyp, der zu 1, 2 und 3 dazugehört)
userGroups = 1,3 (für Benutzertyp, der zu 1 und 3 dazugehört)
....
Folge dieses Konzepts ist ein wahrer Overkill für die Warteschlange des Crawlers oder die Streuung von TSconfig-Einträgen auf alle relevanten Stellen der Site. Beide Varianten nicht gerade fein aber wohl nicht zu umgehen.
Für Benutzertypen, die durch einen passenden Block abgedeckt waren (userGroups entprechend der Gruppenzugehörigkeiten des Benutzers), lieferte die Suche korrekte Trefferlisten. Für Benutzer ohne passende userGroups-Definition gab es nur treffer mit: "Hinweis: Der Inhalt dieser Seite entspricht nicht exakt der Suche. Die Seitenvorschau wird nicht angezeigt."
Könnte jemand ein paar Takte dazu schreiben, wie die indexed search die Datensätze der Tabelle index_grlist erzeugt und nutzt? Dies ist nämlich wohl der Zusammenhang, der die ganze Geschichte steuert.
Zum Schluss ein kleiner Hinweis zur Sprachwahl.
Die Variante &L=[|_TABLE:pages_language_overlay;_FIELD:sys_language_uid] für die URL-Konfiguration der Mehrsprachigkeit gibt es in der Crawler-Doku 2.0 am Anfang des Tutorial-Abschnitts.
Gruß
Kanticus