Use the 'a=' url parameter when passing 'hidden' search strings to a SharePoint search page

On several sites we have links that trigger searches by passing the term GUID to the search page through the 'k=' parameter, as you can see from the URL. This is a neat way of showing all items tagged by a certain term. In fact you can use this method to pass any search string to a search page, not just metadata guids (example: ...resultpage.aspx?k=author:someone).

So this actually works great, but for one thing. I would like to not display the rather cryptic search string in the search box. In addition to the core search results web part on a search page the search box web part also picks up the value passed into the page by the 'k=' parameter, and displays it as the current searched for string.

One solution is to deselect the 'Display submitted search' option in the search box web part properties configuration, but I choose not to because I would like normal search strings entered in the box by the users to display.

After doing a lot of searching for alternatives one of my local MVPs, Mikael Svenson, came up with the easy solution: use the 'a=' parameter instead of 'k='. Has exactly the same effect on filtering the core search results web part, but without displaying the search string in the search box.

One important thing to note is that the core search results web part needs an additional value. Just passing in a value for the 'a=' parameter will return nothing. In my case I added a simple additional query in the 'Append text to query' field in the core results edit web part properties. I used 'IsDocument=1' because I want the search page to list all documents within the defined search scope to be listed if no other search string is given by the user.

Tweaking search results xslt to get document titles to open documents directly in browser instead of Office client

In a recent BI-project we needed lots of Excel files to be opened directly in the Excel web app also when found through search. All libraries were configured to open documents in the web browser, but even so search results always lists all document titles to open in Office clients.

In addition to displaying the document title, the author, description, ++, the default search results also display a separate 'View in browser' link for each document. So the logic was to get the functionality of this link to work for the item document titles instead.

This is quite easy to fix. You have to go into the XSLT file that controls how the search output is put together and do three minor changes. This is preferably done through SharePoint Designer.

I really, really advice you to not do these changes directly in the XSLT found in the web part properties of your search core results web part, but rather create your own XSLT file in SharePoint Designer and link this to your web part like described in Matthew McDermott's great blog.

In your copy of the original XSLT - do the following:

Here is the code that replaces the original div for srch-Title3:

<div class="srch-Title3">
<!-- call custom template to show link to doc that opens in browser-->
<span>
<xsl:call-template name="TitleOpensInBrowser">
<xsl:with-param name="browserlink" select="serverredirectedurl" />
<xsl:with-param name="currentId" select="$currentId" />
</xsl:call-template>
<xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text>
</span>
</div>

Here is the custom template code that I've put right below the original ViewInBrowser template code:

<!-- Custom template to fetch doc title into link that opens in browser-->
<xsl:template name="TitleOpensInBrowser">
<xsl:param name="browserlink" />
<xsl:param name="currentId" />
<xsl:if test="string-length($browserlink) &gt; 0">
<span class="srch-urllink BISearchResultsUrlLink">
<a href="{$browserlink}" id="{concat($currentId,'_VBlink')}"><xsl:value-of select="title" /></a>
</span>
</xsl:if>
</xsl:template>

Also there is the param definition right at the top of the file:

<xsl:param name="TitleOpensInBrowser" />

This should do the trick. All items listed in your search results should now open in the web browser rather than in clients.

Deleting and recreating custom content type managed property killed search scope

Today I had a problem with one of our managed properties. I had created a custom managed property for displaying content type in the search XML and in the search refinement panel. I followed the description from Glyn Clough's Blog: http://www.glynblogs.com/2011/01/create-a-content-type-search-refinement-panel-in-sharepoint-2010.html when setting this up, and everything worked fine except for the problem that for some documents the mime type was listed as the content type instead of the content type's name.

See problem description on Technet forum: http://social.technet.microsoft.com/Forums/en-US/sharepointsearchprevious/thread/2e218709-1f1c-4da1-8bf6-2273b50ce37c/#5d495da5-bec2-4c8a-b960-059784ad5392

To try to fix this I deleted the custom content type managed property and recreated it exactly like I did the first time with same name, mapped it to the same crawled property ows_ContentType, and did a complete recrawl.

That solved the original problem, but now I found that a search scope that had used the original search scope in a rule (customContentType=someContentTypeName) no longer worked. No search results were returned by the scope, and when trying to edit the scope through Central Admin I got an error message stating: "The search service is currently offline...".

I ended up deleting the scope and recreating one exactly the same as the original.

Opening items from core search results in modal popup

I am a big fan of using search instead of for example CQWP, so for listing out a set of news items from one specific list (this part is important) I created a separate search centre site in this project. Instead of sending people to the listed item's original list location when clicking on the item links in core search results I wanted to keep people on the same page for ease and user friendliness when browsing through several news items in sequence. I hence wanted to open each item in a modal popup within the search results page.


Out of the box opening of items from core search results web part




To change this behaviour I obviously had to change the XSL that tells the core search web part how to list it's listed items.

Start by editing the core results web part by clicking “Edit Page” were this Web Parts is placed, then click “Edit Web Part”. In the edit panel under heading "Display properties" uncheck the “Use Location Visualization” checkbox and click "XSL editor". This enables us to edit the XSLT directly in the built in editor (but it's best to copy paste this code into other editor like SharePoint Designer).

To find what lists the original Item Title and Link within the XSLT localize the following:   <div class="srch-Title3"> around line number 300. Just underneath this add the following Javascript:

<a onclick="javascript:NewItem2(event, &quot;http://[listviewurl]&amp;ID={substring-after($url,'ID=')}&quot;);
javascript:return false;" href="[listviewurl]&amp;ID={substring-after($url,'ID=')}" target="_self"><xsl:value-of select="title"/></a>

Thanks to Pete Stilgoe and his article "How to display ‘anything’ in Sharepoint 2010 pop up / modal window" for helping me find the javascript basis.

My javascript is basically built up of three parts: The [istviewurl], the ID=... and the <xsl:value-of select="title"/>.

The [listviewurl] you will find by seeing how the specific list your items live in behave when viewing the items there (where they in fact open modal by design). Go to the list and put your cursor over an item's link, right click and copy it's link.

You will find similar to this: http://server/site/_layouts/listform.aspx?PageType=4&ListId={63628054-BF65-4FB2-9A60-8EBBEB659640}&ID=2&ContentTypeID=0x0100B0CD2426D905CB4FABC1450EF4289FC9004FAC50F90D5C224EA8956A6A6CB9D6C6

Except for the ID=2 part, this is your [listviewurl] in the javascript.

The ID=2 is of course the ID of the specific list item, so this needs to vary for each result in the search list. To find each item's ID you need this in your XSL: &amp;ID={substring-after($url,'ID=')}". What it does is to use the built in variable $url (each item's search result list URL) that of course also includes the item's ID, and extract just the ID.

Then lastly the <xsl:value-of select="title"/> lists out the item's title as the clickable part of the javascript code.

Using my list details the complete javascript comes out as:

<a onclick="javascript:NewItem2(event, &quot;http://server/site/_layouts/listform.aspx?PageType=4&amp;ListId=63628054-BF65-4FB2-9A60-8EBBEB659640&amp;ContentTypeID=0x0100B0CD2426D905CB4FABC1450EF4289FC9004FAC50F90D5C224EA8956A6A6CB9D6C6&amp;ID={substring-after($url,'ID=')}&quot;);
javascript:return false;" href="/site/_layouts/listform.aspx?PageType=4&amp;ListId=63628054-BF65-4FB2-9A60-8EBBEB659640&amp;ContentTypeID=0x0100B0CD2426D905CB4FABC1450EF4289FC9004FAC50F90D5C224EA8956A6A6CB9D6C6&amp;ID={substring-after($url,'ID=')}" target="_self"><xsl:value-of select="title"/></a>
Now, I'm no javascript expert so I'm not sure what the two almost similar url parts do, nor why they are not exactly the same when it comes to formatting. But it works!

Looking at the code in SharePoint Designer it looks like this:

As you can see I have commented out the original code that lists out the result list titles.

And the result: Voila!