SharePoint 2010: Multiple Search Core Results Web Parts vs. the 's' URL Parameter

Anyone who has ever set up a search page on a SharePoint 2010 site collection knows that URL (query string) parameters drive much of the search functionality.  The ‘s’ parameter provides the ‘scope’ that will be used, in conjunction with the user query (‘k’ parameter), to the search core results web part(s) on the page.  The ‘s’ parameter is passed to a search page when the ‘scope dropdown’ is enabled on a site collection, and a user performs a search using the shared search box that is found at the top of most sites.  When the user is on a search page, the ‘s’ parameter is typically not passed in the URL when the search box web part is manually added and used on a search page. 

The search core results web part allows the user to configure a ‘scope’ (under ‘Location Properties’) that will be used when the ‘s’ parameter is not present.  The following site is a great resource where you can learn about all of the configuration options for the search core results web part: http://technet.microsoft.com/en-us/library/gg549987.aspx.  

Recently, I had a request to set up a search page that could display the full results from a particular scope sorted by relevancy, and the top 5 related results from a different scope sorted by modified date.  Additionally, both web parts had to display results based on the user’s query (k parameter).  The page was configured as the target results page for one of the scopes in the site collection 'scope dropdown' control, and the "primary" search core results web part on the page was configured to use the 'scope dropdown' value.  At first, this seemed like a fairly straightforward effort.  I added two core results web parts to the page ("primary" in the center web part zone), applied unique XSL to each web part, used the scope property to define my scopes for each web part, configured sorting and paging options, and changed the ‘Cross-Web Part Query ID’ to ‘Query 2’ for the web part I titled "Top 5 Related Results" (placed in the right hand web part zone).  

It is important to note that the ‘Cross-Web Part Query ID’ property must be updated on each of the search core results web parts on a page if results from multiple scopes are going to be displayed on a page.  If all of the search core results web parts use the ‘Query ID’ of ‘User Query’, they will all perform the same initial query using the same scope.  Additionally, expect to see some truly facinating results if “Fixed Keyword Query” or “Append Text To Query” options are used on any of the search core results web parts when all of the web parts use the same ‘Query ID’.  Additionally, updating this property essentially disconnects a web part from other search web parts on the page (such as the refinements web part), unless those web parts are updated to also use the same ‘Cross-Web Part Query ID’ value.  That said, there are scenarios where you may want to use the same ‘Query ID’.  For instance, you may want to use the same ‘Query ID’ on two search core results web parts if both need to query the same scope, but one needs to be sorted by relevance and the other by modified date.  

After setting up all the web part properties, I performed some test searches using the search box web part I had configured on the page.  Everything was working great, and I was getting ready to call this a great success.  Results from each distinct scope were being displayed in the appropriate web parts, and the user query was updating the values in each web part accordingly.  However, after conducting additional testing using the shared search box web part, which is typically found at the top of most sites, I quickly came to the conclusion that my work was not yet done.

Note: The following likely does not need to be completed if your page is not targetted by one of the scopes in the 'scope dropdown' control (displayed at the top of most sites).

Remember when I stated, “the ‘s’ parameter is passed to the search page when the ‘scope dropdown’ is enabled on a site collection, and the user performs a search using the shared search box”?  Also, remember when I stated that the ‘scope’ property on a search core results web part is only used when, “the ‘s’ parameter is not present”?  Essentially, this meant that when I selected the scope from the 'scope dropdown' that was targetted to the page I had configured, the ‘s’ parameter was also passed to my page along with the user query.  This then resulted in all of the search core results web parts on the page utilizing the same scope regardless of how the ‘scope’ property was configured on each web part. 

To overcome this functionality, I had to create a third scope, which I will refer to as “Aggregate”.  Of course you would not call this scope “Aggregate” in a real world scenario, because it is the scope that needs to be displayed in your 'scope dropdown'.  The “Aggregate” scope was configured to include the two existing scopes (for our purposes, lets call these "ScopeA" and "ScopeB"), and the search page I had configured was set as the "Aggregate" scope's target results page.  Next, I updated the “Append Text To Query” property (under “Results Query Options”) on both web parts I had previously configured to filter the results as needed. 

Let us imagine that the "Top 5 Related Results" web part should only display results from “ScopeA”.  I updated the scope on the "primary" search web part (in the center web part zone) to use the “Aggregate” scope (composed of "ScopeA" and "ScopeB"), and added the following text to the “Append Text To Query” property: ‘scope<>ScopeA’.  Next, I went to the "Top 5 Related Results" web part and added the text ‘scope:ScopeA’ to the “Append Text To Query” property.  Those formulas should be pretty straight forward, but the following site is a great resource that can help you configure the “Append Text To Query” property if you need to write more complex queries: http://msdn.microsoft.com/en-us/library/ff394509.aspx.  After setting these properties, everything was working as expected, whether the 's' parameter was present in the URL or not.  Results from "ScopeB" were being displayed in the "primary" search core results web part, and results from "ScopeA" were being displayed in the "Top 5 Related Results" web part.

Main Web Part PropertiesTop 5 Related Results Properties

From my testing, creating the "Aggregate" scope was a necessary step for my particular scenario.  Remember, no matter what scope properties you define in the search core results web part, the ‘s’ parameter is going to take precedence.  When the ‘s’ parameter is referencing a scope that includes all scopes needed on a particular search page, the “Append Text To Query” option works as expected.  If we simply provide the text “scope:ScopeA” to the "Top 5 Related Results" web part, and do not create an "Aggregate" scope, the web part in my example will not display any results when the ‘s’ parameter is equal to any scope other than "ScopeA" (or a scope that includes "ScopeA").

The only real downside to this approach is you potentially have one more scope to manage.  You can circumvent this if you use the ‘All Sites’ scope, and use the ‘AND’ operator to filter out all necessary scopes using the “Append Text To Query” property.  Alternatively, you could consider simply updating one of the scopes to also include the results from the other scopes needed on a particular target results page.  Additionally, you could always consider completing custom development to extend the 'search dropdown and shared search box control' to pass the 's' parameter differently.  Regardless of the approach you take, I would definitely advise conducting extensive performance testing to ensure that your solution does not affect the overall user experience in a negative way in regards to search response times.

One final note, when the “Append Text To Query” property is used the search core results web part is always going to display a result, even if the user has not provided a query.  Depending on your use case, always providing results may or may not be a desired behavior.