Debugging Legacy Core Search Results Web Part in SharePoint 2013

Another in my series of past SharePoint adventures, and lessons learned, that finally gets to see the light of day.

A while back I helped migrate a client’s SharePoint 2010 site collection to SharePoint 2013. After we re-attached the content database in the SharePoint 2013 farm, we did not upgrade the site collection to the SharePoint 2013 experience, we left it with the SharePoint 2010 experience. The site ran as expected, but we ended up having issues with search results returned by Core Search Results Web Parts (CSRWP).

In particular, one core search results web part was configured to search only for items of a particular custom content type within a particular path. This web part was also configured to use a custom XSL Style Sheet. The results were supposed to return a series of columns including custom columns. After the site transfer, the custom columns were no longer being returned by SharePoint and thus were not displaying in our search results.

After much trial and error, I found the following process worked wonders

To start, there was a custom Managed Property in particular that would not display. The managed property in this case was url. Within the custom XSL Style Sheet, we wanted to display this Managed Property using a <xsl:value /> control, i.e.

This was returning an empty string which should not be the case.

To begin debugging, I wanted to see all of the raw data that was being returned by search. I ran some magic Google searches and came across the following article on debugging search by Agnes Molnar. This article then referenced a SharePoint 2007 article by Matthew McDermott on configuring XML results. And this article in turn referenced a MSDN article, which is exactly what I needed. I provide all three references as each article was another brick in the path to success.

So now I could see all returned columns with their values for results returned by Search to my CSRWP. At this point I noticed that columns that I expected to have been included were not available, or did not have data. I knew the data was there, but it was not returned.

Next step was to review my Managed Properties in the Search Service Application this Web Application was associated with. Yes, I am a branding guy, but basic search administration should be in any SharePoint developer’s toolkit. In Central Admin, I went to “manage service app” then I clicked on my “search application” and finally “search schema”. I ended up not being happy with the managed properties that were transferred over from the original server, so I created my own. I created a new managed property, marked it as retrievable and associated it with my custom column crawled property.

After a full crawl (always have to remember that full crawl for new managed properties) I returned to my page with the CSRWP and reviewed my results. No change. Ah, I forgot to add the columns to the web part, that was next. After editing the CSRWP properties, under Display, I made sure the properties listed included the newly added managed property. In my case I added URLOWSURLH.

Now my results page showed the columns I was expecting in the XML test results! It was time to revert to having the CSRWP use the custom XSL Style Sheet and not display results in raw XML.

I updated the XSL Style Sheet to use this new column in place of the old {url} we were using before.

Became

After loading the results again, no luck! I knew that the column was returned as I saw my custom column in the debugging XML results, but now I could not reference it in my custom XSL Style Sheet. After trial and error I found that the XML results contains a tag <urlowsurlh />, all lowercase! I did not know that this was case-sensitive.

I changed my xml:value control to the following which solved my problem.

All was good with the world.

If you run into a similar issue debugging your SharePoint search results I recommend you look at your managed properties, then make sure your results web part is requesting the correct managed properties and finally make sure that that your value properties in your XSL Style Sheets are of the right case. If you get stuck, I highly recommend you configure your web part to return XML as referenced above as that will likely help you track down the column name(s) and verify that data is returned.

Or upgrade to the SharePoint Online/2016/2013 search web parts that use Display Templates! Much easier to work with and debug than XSL Style Sheets.

Special thanks to Chris Givens (MVP) for his help with this problem.