Can the Search Core Result Web Part REALLY do magic?

Finally I found the answer for a strange behavior of the Search Result Web Part, at least as it occurred to me and a couple of expert-friends I also asked for help.

The Situation

When wanting to customize how Search Results are displayed, one has to follow this approach:

Add for example your own new custom field to a list or library. Lets name them “ThomasTag”, “ThoamsDescription” and “ThomasArea”.

(Screenshots are taken from live system, I changed / faked the field names for this blog)

Then start a Full Crawl to get them as “Crawled Properties”

(Be sure to have some values in this fields, BEFORE doing a full crawl. Otherwise, the fields will not be available!)

Next, we need to map each Crawled Property to a new “Managed Property” to have them available as Search Refiners, and to use them later for Customizing the Search Results (via Xslt).

(More here for this step: How to: “View and Edit the Search Results XSLT Transformation” )

Be sure to map your custom fields to the “ows_” Version of a found crawled property, as this reflects the so called “SharePoint Field”, which means, this is the field coming direct from the list.

Also, it may come important, to check the Checkbox “Reduce storage requirements for text properties by using a hash for comparison”.


To view the XML-Output of the query, take a Search Core Result Web Part, click on “Edit Page” were this Web Parts is placed, then click “Edit Web Part”.

Important here: Uncheck the “Use Location Visualization” checkbox, then it is possible to change the Xslt Output:

In the XSLT-Editor (or better in an Xml-Editor of your choice) just replace the current Code with this code:

<?xml version="1.0" encoding="UTF-8"?>
 <xsl:stylesheet version="1.0" xmlns:xsl="">
 <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
 <xsl:template match="/">
 <xmp><xsl:copy-of select="*"/></xmp>

You may want to save the current code to be able to revert this setting. Otherwise you may need to delete this Search Core Result Web Part and place an new one, which will bring these default values again.

More details here: “How to: View Search Results XML Data”,

To be able to see – and use – your Custom Fields which are now “Managed Properties”, you will have to put them in a Property of the Search Core Result Web Part which is called “Fetched Properties”.

See sreenshot above., and here: “How to: Change the Properties Returned in the Core Search Results”,

Click Ok and “Stop Editing” the page.

Now you should see the XML-Version of the Search Result, including your new “Managed Properties”.

You can also use, of course, these new “Managed Properties” as so called “Search Refiners”, as well in the Search Refiner Web Part” on this Search Result Page, as you can use the Managed Properties as new keyword for searches in the Search Textbox:

Use your custom “Managed Properties” as Search Refiner in the Search Refiner Web Part, here: “Filter Category Definition”

Be sure to UNCHECK this tiny small Checkbox “Use default Configuration”.

Doing NOT so, will result in the fact, that whatever you try to enter in the “Filter Category Definition” will not apply, because it will not even be SAVED!


Find more on this, here: Michal Pisarek, “Adding Search Refiners in SharePoint 2010″,


Now here comes the point:

I tried to remove my new “Managed Properties” from the “Fetched Properties” settings in the Search Core Result Web Part.

What I expected was, that my new fields then would not appear in the XMl-Output anymore.


Developer often ask: “Why doesn’t my result show up?”, this time I asked myself: “Why DOES my result show up?”

I had no idea.

I made quite a looooooooooooot of chance here and there, but still. The fields showed up for no known reason.

A expert-friend BTW speculated, that they (the new Managed Properties” fields might have found their way into to default configuration, which can be made for the Search Core Results in the Central Administration.

Wow: I did not know this until yesterday. Thanks, Tobias Wolter (

These settings are available in: Central Administration > Search Sevice settings > Edit Federated Location:


Default Values for the Search Core Result Web Part in the Central Administration:


BUT: they were not there, because I did not put them their (I did not even knew this settings), and SharePoint does not THAT much magic, as one may believe. Sometimes :-)

So still I asked myself: Why do my fields show up, although I did have them entered anymore in the “Fetched Properties” settings?

Another assumption could have been, that the “Managed Properties Cache” could have something to do with this.
There are very little details about what the “Managed Properties Cache” actually is – and does.
But it seems, that this did not help, either.


Additional tests gave me the – somehow “strange” reason – and led towards the solution:

The solutions lies in the fact, that they were also entered in the “Search Refinement Panel” Web Part.

This surprised me a lot, because of the fact, that these Web Parts do “just the following to provide themselves with date and to build the output:

They all just sneak at the URL of this page and do what they have to do. I did not see a reason, why one Web Part would know what the other do.

But in fact, they DO!

The reason for this lies in another setting of these Web Parts, which everyone may occasionally have seen, but never spend more attention: the “Cross-Web Part query ID”

I already knew, that when one was placing MORE “Search Core Result Web Parts on one page, on has to turn off their connection using this setting.

More here:


I had no idea that also this setting exists in the “Search Refinement Web Part”!

So when removing my new “Managed Propertes” from the “Filter Category Definition” field, or changing the “User Query” id to another value then my “Search Core Result Web Part, where I still have the XML-Output set, will finally lead to the result, that these “Managed Properties” vanish from the XML output.

So finally I got back the feeling, having control over what happens here :-)

(At least a ‘bit  :-)    )


Hope this helps somebody out there.

Best wishes,



Leave a Reply