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 http://kwizcom.blogspot.com/2008/11/how-to-change-moss-search-retults-sort.html 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:

to the following:

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

Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart

Phase 2 of our project will use a combination of Server Side customization (as described at http://msdn.microsoft.com/en-us/gg620579) by extending the CoreResultsWebPart
and the jQuery approach above for easy inline searching of accessible site collections.