This post is an addition to my previous post about SharePoint people search.
While building a custom “CoreResultsWebPart” we noticed that some people were not being returned in our search results by the default search.
1) But when we searched it with our custom code it did return results.
2) When a french speaking collegue of mine searched using the same webpart he did get the result, but only when he logged into the machine, not just by signing into my IE Sharepoint.
When going to the SharePoint logs I found that the query did the following when I searched for “Leemans”:
0x231c0031
Type="Synonym">10x00006c00650065, lee
PID="0x7fff7fff" len="13">0x00006c6d0061006e, leeman
len="19">0x00006c6d0061006e006e0065006e, leemannen
len="15">0x00006c6d0061006e0073, leemans
1
Count="3">0x00006d0061006e, man
len="13">0x00006d0061006e006e0065006e, mannen
0x00006d0061006e0073,
mans
Type="Unknown0x16777206">
...
So the query automatically (also for out of the box Sharepoint people search!) used synonyms to change my queryterms.
After some Reflector work on the “SearchResultHiddenObject” class I found the following:
try
{
if (!string.IsNullOrEmpty(this._QueryLanguage))
{
myRequest.Culture = new CultureInfo(this._QueryLanguage);
}
else if ((this.thisPage.Request.UserLanguages != null) &&
(this.thisPage.Request.UserLanguages.Length > 0))
{
myRequest.Culture = new CultureInfo(this.thisPage.Request.UserLanguages[0]);
}
}
Which means if the param _QueryLanguage isn’t filled in, it used the users language which explains why my french speaking collegue did get results. The french synonym list wasn’t creating issue’s, nor was the english one, just dutch.
By adding the following code to my already custom webpart I could set the parameter and garanty that each user use the same, english synonym list.
+ I added some code so the maximum returned results by a query isn’t limited to 50.
public class xxxwebpart: CoreResultsWebPart
{
....
protected override void SetPropertiesOnHiddenObject()
{
base.SetPropertiesOnHiddenObject();
// Get Reflection info
object srho = this.GetType().InvokeMember("srho", BindingFlags.GetField | BindingFlags.Instance | BindingFlags.NonPublic, null, this, new object[] { });
Type type = srho.GetType();
//Set RowLimit
type.InvokeMember("_ResultsRequested", BindingFlags.SetField | BindingFlags.Instance | BindingFlags.NonPublic, null, srho, new object[] { ((short)1000) });
//Set Query Culture to en-GB to use this synonym list which causes no problems
type.InvokeMember("QueryLanguage", BindingFlags.SetProperty | BindingFlags.Instance | BindingFlags.Public, null, srho, new object[] { "en-GB" });
// Allow the query to be reissued
type.InvokeMember("ForceRerun", BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.Public, null, srho, new object[] { });
}
Seeing as the dutch synonym list was not changed but default, I think we can assume all the out of the box people searches for Dutch users will sometimes give no results because of the synonym use…
As a quick fix for users that don’t use a custom CoreSearchResults webpart I’ve created a simple webpart called SearchQueryOptionsWebPart that does 2 things:
- Sets the culture for the query so you can determine per page which Culture (read which synonymlist) should be used by all users.
- Sets the rowLimit for the query to return. I’ve noticed that a lot of people are also looking for an easy way to increase this above the hard limit of 50.
You can find the sourcecode here.
Just install the wsp, activate the site collection feature “MOSS2007 Search Query Options WebPart (SQOW) ” and add the webpart to any search result page where you want to set the options.
The default for the options are “en-GB” and 1000 (rowlimit) but you can change these easily in the webpart properties.
Gr
Tom