Thursday 1 December 2011

SharePoint 2010 - Modifying the Core Search Results Web Part to Display Results Sorted by Site Name or Document Title (With Paging Limitations...)

I recently had a requirement from my client to have the following functionality in SharePoint 2010:
a) The Search Core Results web part displaying sorted in Alpha order
b) The Search Core results part should just show sites (not documents) that the current user has access to.

Requirement b) was simple - you can set the keywords on the Core Search Web Part to just display sites (using the "contentclass:STS_Site" keyword in the "Fixed Keyword Query" property - and the part would default to showing a list of sites the current user has access to (via the normal SharePoint 2010 security trimming functionality).

However, the first requirement was a little bit trickier. The default Core Search Web part only provides for 2 search sort options - by date and by relevance (which is the default).

To fix this, the XSLT which defines the search results needs to be changed. This XSLT is specific to the instance of the web part - modifying it won't affect the normal search functionality of your site.

To modify the XSLT for the search results web part, you need to first uncheck the "Use Location Visualization" checkbox. The XSLT that opens is around 700 lines long and has a lot of different XSL templates defined within it. To sort the search results by alpha order, you need to use an xsl-sort call within the main apply-templates call.

Some sites such as have a simple suggestion - but this would not work as the "select node is missing" on the "apply-templates directive. You need to provide a valid parent to allow for sorting. The fix was to change the empty apply-templates node in the default search XSL:
<xsl:apply-templates />

to the following:
<xsl:apply-templates select="All_Results/Result">
    <!-- The xsl-sort needs operate upon a single field - it doesn't work if the sort has to evaluate child nodes--> 
    <xsl:sort select="title" />

Note that I didn't require the other elements in the Search XML (the TotalResults and the NumberOfResults nodes), so this solution may not work in your scenario. This list can then act as a facility for cross-site collection navigation (which is not available out of the box in SharePoint 2010)

Another limitation of this approach is that it will only work on a non-paged resultset - which is a pretty major limitation! In our scenario (for Phase 1 of our provisioning solution), it was acceptable for our customer to increase the page size to avoid any pagination from occurring. Your mileage may vary.

Other solution options are:
  1. Scripting - Using jQuery to do a search call and sorting and paging the results yourself
  2. Server side - with your own custom web part that also does the paging for you - using the SPGridView or inheriting from
Phase 2 of our project will use a combination of Server Side customization (as described at by extending the CoreResultsWebPart
 and the jQuery approach above for easy inline searching of accessible site collections.


Jim's Blog said...

Thanks so much! I had the same general requirement (for an "in-page" alpha sort of sites that the user has access to), and this saved me a ton of hours, since I don't have much knowledge of XSLT. Much appreciated!!

Kimberly said...

How would I Display the search core results, grouped by site collection/site? I did find that if I placed the advanced search parameters in the fixed keyword search it would display the proper results. I added the contentclass:STS_Site to the append keyword field and it did make the sites display.

Unknown said...

Next Digital Health said...

Thanks for sharing this information. Next Digital Health is the Best Healthcare Blog in the USA . Read about some of our blogs like Health sector releases threat brief from Log4J security vulnerabilities and Mobile Health lacks interventions for Mental Illness . IBM cracks a deal with Francisco Partners to share healthcare data and ONC will now exchange framework facilitating better interoperability on our website.