Search preview is one of the nice features which was introduced in Sharepoint 2013. It gives possibility to see the target page without redirecting on that page. Preview may work for basic html pages or for documents (e.g. content of Word, Excel, Powerpoint documents can be shown in preview window). Some time ago we faced with one strange problem, which is platform bug from my point of view: for pages with friendly urls search preview doesn’t work. I.e. if for pages which have regular structural urls (http://example.com/pages/foo.aspx) preview panel looked like this:
then for pages with friendly urls defined in managed metadata term store (e.g. http://example.com/foo) it looked like this:
The key for solving this problem is in display template used for the page. Or to be more accurate, display template for hover panel used for the item. As you probably know for most items there are 2 display templates:
- for rendering item in search results;
- for hover panel for rendered item.
First “basic” display template has reference on second “supporting” display template in its code. By default Sharepoint uses standard Item_CommonItem_Body.html display template for items in search result (it may be overridden for different content types by search result types). Some time ago I wrote about how to modify this display template for fixing another Sharepoint problem, see Problem with cut titles in search results in Sharepoint 2013. In this article I will continue to work with the same display template, however you may use this approach with any other display template.
Later in the code it is used like this:
i.e. in onclick attrbiute of the item’s div. Second place where it is used is a link with item’s title:
Here it is used in onfocus attribute for the link which points to the target page.
and if result is true (i.e. if callback in ctx.currentItem_ShowHoverPanelCallback is null or undefined), it creates callback by itself. And it uses the following display template for the hover panel: ~sitecollection/_catalogs/masterpage/Display Templates/Search/Item_Default_HoverPanel.js.
My first thought was just to replace Item_Default_HoverPanel.js on Item_WebPage_HoverPanel.js in the code above. However as it turned out code, which constructs callback function, is not called for most of the items (moreover it has a bug, because itemId variable defined as itemId = id + Srch.U.Ids.item will be incorrect. It will end with “_item_item” and will point to not-existent html element). It means that Srch.U.n() function returned false, i.e. callback was defined in ctx.currentItem_ShowHoverPanelCallback for most of the items. I added tracing with console.log() for ctx.currentItem_ShowHoverPanelCallback and found the following:
for pages with regular structural urls it contained something like this:
while for pages with friendly urls it shows this:
The key difference is in display templates used for hover panel: in first case Item_WebPage_HoverPanel.js is used which supports previews, while in second case Item_Default_HoverPanel.js is used where previews are not supported. After that another solution came to my mind: we need to construct callback function by ourselves for all items using Item_WebPage_HoverPanel.js display template. But how to do it? As callback is defined in ctx.currentItem_ShowHoverPanelCallback (which technically may be done on server side or in earlier steps in call stack on the client side), it may be hard to intercept the code where it is created. Much simpler to do it directly in display template.
Here is how it can be done. Instead of code shown above we need to use another code:
First of all we create correct ids of the divs for item itself and hover panel (lines 5-12). As I wrote above, code in OTB display template is incorrect: id variable which is used as a base already contains “_item” prefix, so we don’t need to add “_item” and “_hover” to it directly. After that for hoverUrl we use Item_WebPage_HoverPanel.js display template which supports previews. The last interesting part is how we attach created callback to the parent div, which is used as container for the item in search results. We can’t do it synchronously in the code, because this DOM element is not ready on the moment when the code is called. So we add it asynchronously by adding custom post render callback (lines 19-21).
After that you need to reupload Item_CommonItem_Body.html display template to /_catalogs/masterpage/Display templates/Search folder and publish it with major version. If you have several site collections you need to do it on all site collections separately. And the last thing: if you don’t want to change OTB display template, but instead want to create custom based on it and change this custom template, then in order to ensure that this display template is used on your search results page, you need to assign it to the ItemBodyTemplateId property of the ResultScriptWebPart on the target page for search requests:
After that it should use your custom display template for the search items.
That is all which I wanted to write about fixing problem with search previews for pages with friendly urls in Sharepoint 2013. In future articles I will also show how to enable search preview for list items in search results, which is also not available by default.