Tag Archives: Search

SharePoint Search & Migration Part 4: Search Result Types and Display Templates

In a few series of posts I will discuss changes in SharePoint Search which might affect you when migrating from SharePoint 2010 to 2013. Search is one of the most changed components in SharePoint 2013 and therefore I split the posts up in four parts covering some subjects you need to know before migrating to SharePoint 2013. All parts will be available with the links below when the posts are available:

Part 1: Search Settings
Part 2: Search Web Parts
Part 3: Search Results Sources
Part 4: Search Result Types and Display Templates

In this post I’ll discuss Search Result Types and Display Templates. Both are new features coming with the new Search platform in SharePoint 2013. You’ll need them in case you want to customize the way how search results are displayed. In the past XSLT was the way to go by changing the search results page and change the Web Part settings XSLT. In 2013 this functionality is no longer available and Results Types and Display Templates are the way to go.

Let’s focus first on Result Types. Microsoft provides on MSDN a nice article which gives you a basic understanding of what it is. In short: when searching you’ll get results back of different types. A site is different from a library, a word document is different from an excel document or image, etc. Each type of result is defined as a Result Type. Out of the box a set of result types is predefined like all types of Office documents, pages, sites, libraries, etc. Per type a Display Template is coupled which determines how the result of the specific type should be rendered in the Search Results Web Part. Result types are managed per Site Collection and Web. In the Site Settings menu you can select Search Result Types for managing them on Site Collection level and Result Types to manage them on Web level. After opening the page you’ll see a screen with all result types on the site collection or web:

Manage Result Types page for Site Collection Administrator

All out of the box delivered Result Types are read-only. This is similar as with Result Sources, where the out of the box settings are also read-only. When we open one of the Result Types we can see how it’s configured and what you can configure:

View Result Type page

For each Result Type you can specify the name and conditions. The conditions filter first on Result Sources. You can also select the option to use all if you don’t want to filter on it. Next you can filter on the type of results. This is a predefined set of types which SharePoint recognizes. When you expand “Show more conditions” you have the ability to create filters based on Managed Property values. In case you have added additional fields to specific content types and you want to filter on them you can use this functionality to add a filter. The last option you need to select a Display Template. This list is created based on the approved Display Templates in the Master Page Gallery (in the subfolder Display Templates). This is actually the template that is used to render the Search Result which is matching this Result Type. When created it will appear in the top section of available Result Types.

Now we have discussed the Result Types we can focus on Display Templates. Display Templates are the replacement for XSLT and provide a powerful way to create templates within SharePoint. Microsoft has again a good article about what a Display Template is. Display Templates are stored inside the Master Page Gallery in a subfolder called Display Templates. Inside that folder there a some subfolders for specific categories of Display Templates. In our case we need to open the Search folder and that should look like the screenshot below:

List of Search Display Templates in the Master Page Gallery.

In case the Publishing Infrastructure feature is not activated on the Site Collection, you’ll only see .js files. Be aware of this! In that case if you don’t want to activate it and want to create or change display templates, read this article from Martin Dreyer where he describes how to change display templates on non-publishing websites. On publishing websites you should ignore the .js files. They are automatically updated by SharePoint when you make changes to the HTML files. The MSDN article which I’ve shared already describes how you can change Display Templates. You can adjust them to display for example additional Managed Properties or change the styling. On the internet you can find a bunch of examples to built-in pretty cool stuff with display templates. A small selection is stated below:

– Add twitter links using Display Templates
– Image Slider
– Customize Display Templates and deploy them using a solution

SharePoint Migration & Search Part 3: Result Sources

SharePoint Migration & Search Part 2: Search Web Parts

Leave a reply

Part 1: Search Settings
Part 2: Search Web Parts
Part 3: Search Results Sources
Part 4: Search Result Types and Display Templates

In this post I will describe the changes to Search Web Parts in-depth. These Web Parts were changed as part of the new search platform which is available in SharePoint 2013.

First thing you’ll notice when using SharePoint 2013 is the number of search Web Parts available. When you want to add a search Web Part you see that the number of Web Parts has been reduced drastically.

When you look to this list at the first time it looks like a lot of search functionality is missing in SharePoint 2013. But that’s not right as we will see later. The best way how to show that is on the results page in a OOTB Search Center and let’s see the difference in number Web Parts in edit mode.

The search results page in a search center in SharePoint 2010 contains a lot of Web Parts to display all information.

Let’s compare this to the same page when using a SharePoint 2013 Search Center:

The Search Results Page in SharePoint 2013 contains only a few Web Parts.

There is a simple clarification for this enormous reduction of a number of Search Web Parts and that is integration. The new Search Result Web Part is now containing the functionality of a lot of other Web Parts like the Search Paging, Search Statistics, People Search Results, etc. This is a major advantage when maintaining and configuring search Web Parts.

Another major change is the way how the Web Parts are configured. In 2010 and before XSLT was the way to go when changing the search results being displayed. In 2013 this has been removed and you need to use Display Templates. Those Display Templates can be coupled to Result Types. Based on the type of search results you can customize the way search results are displayed. I will cover this more in-depth in part 3 of these series of articles. This implies that you need to change your customized search functionality in your solutions if you’re using it and want to use customized search results.

As probably already noticed Search Scopes are deprecated in SharePoint 2013. Deprecated means that no new scopes can be created and existing scopes are read-only (this is also blocked from API). This also has implications for the Search Web Parts. The new Search Web Parts don’t provide support for Search Scopes but only for result sources. For example, the scopes drop down functionality is no longer part of the Search Box Web Part.

Another thing to mention is the Site Collection Upgrade. When using a standard Search Center without modifications there is nothing to be done. The Site Upgrade handles the transition automatically. In case you are using search Web Parts outside a Search Center the upgrade process does not replace the Web Parts! This will results is some glitches.
First problem you’ll notice is the styling. The old Web Parts do not comply with the 2013 style sheets which results in big buttons and other similar ugly glitches. Make sure you have an upgrade strategy ready for this and mitigate this using custom feature upgrades or manual steps after the Site Upgrade! Replacing the Web Parts can only be done after Site Upgrade. The 2013 Search Web Parts won’t work when in 2010 mode!
Another thing I’ve noticed is that when still using the old Web Parts in 2013 mode, is that the search scopes are not respected anymore. SharePoint uses in 2013 a different way of creating the search URL’s and these are not compatible with the old Web Parts. That results for example that an All Site scope search automatically results in a search on whole SharePoint. Again the only way to resolve this is by replacing the Web Parts. An approach there is to create new 2013 search pages in your solution in a subfolder and using a feature reactivation provision these on new sites and also update the search configuration as mentioned in Part 1 of the series.

To conclude this post I will provide an overview of all Search Web Parts available in 2010 and 2013:

SharePoint 2010	SharePoint 2013
Advanced Search Box	Advanced Search Box*
Dual Chinese Search	Search Box
Federated Results	Search Navigation
People Refinement Panel	Search Results
People Search Box	Refinement
People Search Core Results
Refinement Panel
Related Queries
Search Action Links
Search Best Bets
Search Box
Search Core Results
Search Paging
Search Statistics
Search Summary
Search Visual Best Bet
Top Federated Results

* The Advanced Search Web Part is missing in the Web Part gallery but it still part of SharePoint. It is still possible to use that Web Part, but you need to export it from a Search Center and import the .webpart file in your site to use it.

SharePoint Migration & Search Part 1: Search Settings

1 Reply

Part 1: Search Settings
Part 2: Search Web Parts
Part 3: Search Results Sources
Part 4: Search Result Types and Display Templates

In this post I will cover the search settings in-depth. But first some general information about what has happened to the Search component in SharePoint 2013 compared to 2010. In SharePoint 2010 we had actually three options for search:
– SharePoint Foundation Search
– SharePoint Enterprise Search
– FAST

In 2013 the FAST search engine is fully integrated into SharePoint and there is only a difference in features for search based on the three types of licenses (Foundation, Standard and Enterprise). See a list of feature comparisons for a quick overview for differences between editions within search. This automatically implies changes to the search functionality on different levels. In this post we’ll focus on the Search Settings for Site Collections and Sites where some things has been changed.

In SharePoint 2010, Search Settings could be managed per Site Collection using the Search Settings link when going to Site Settings:

Search Settings Link in 2010 on Site Settings Page

On the Search Settings page itself you were able to set settings like enabling custom scopes, set the drop down mode for Search Boxes and specify the Site Collection Search Results Page. Those settings where actually kept in the property bag of the rootWeb of a Site Collection. See the picture below for the mapping of the properties in 2010:

Search Settings in 2010 with Propertynames of properties stored in propertybag

* Note the spell error in the Search Results Page propertyname. This was a spell mistake which was there in the SharePoint product itself.

When you upgrade a Site Collection using Visual Upgrade or so-called Site Collection Upgrade to 2013 mode we will notice a few differences. First when we browse to the Site Settings page you’ll notice two Search Settings links. The first one on the left is on Site Level and the second one on the righ is on Site Collection Level:

Search Settings are in 2013 available on two different levels.

When browsing to Site Collection Level Search Settings you’ll notice that all settings from before the upgrade are lost:

Default Search Settings after visual upgrade. All customized settings seems to be lost.

As you see in the screenshot all old settings seems to be lost and reset to default values. When diving into the property bag on the rootWeb we’ll notice that internally new properties are used to store the settings and the Visual Upgrade doesn’t migrate those settings automatically. I’ve marked the properties in the next screenshot for Site Collection Level:

Search Propertynames mapped to the settings in the User Interface in 2013.

As you can see two new properties have been introduced. You’ll also notice the SITE in the name of the property. This has to do with the scoping of the search settings. When you store these settings on a web, then the SITE in the property name is replaced with WEB. The setting which is the lowest in the tree takes precedence. So if you set it on Web Level, that web will only look at the web setting, otherwise it will look at Site Level. The following schema shows how the settings are actually stored per level:

In the schema some examples are shown. Lets start with Web 2 which is a sub site under Site Collection 1. On Site Collection 1 the search settings are applied and stored in the property bag of the rootWeb (haven’t shown this in the schema to keep it clean). Because Web 2 doesn’t have specific Search Settings it will by default take the settings from the Site Collection 1. Web 1, which is also a sub site under Site Collection 1 has specific settings on Web Level and will use them instead of using the Site Collection Level settings. There’s also one exception which is not shown in the schema. You can set the Search Center URL also in the Search Service Application and then also all associated Web Applications can use that setting. But it will only be used when it is not set at Web or Site Collection Level! The screenshot below shows where you can specify this setting on Service Application Level:

Search Center URL can also be specified in Search Service Application.

For the inner structure of the properties I want to refer to the article of Radu Tut about Search Box Settings as there is already written a lot about this on the internet. A scenario which hasn’t mentioned a lot is how you can migrate the old settings to the new ones. It cannot be done OOTB, you’ll need PowerShell scripts, custom-made CSOM tooling or Server Side Code to do this. When you are using custom Farm solutions with a custom feature to set the Search Settings it might be very powerful to use Feature Upgrades to apply the new settings using code. In combination with the article of Radu Tut you should be able to create an upgrade yourself and invoke it using Powershell Scripts.