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.

How to set hyperlink url and display name in Sharepoint Designer workflow

A Hyperlink field is made up of two separate parts, the clickable display name and the actual URL. In SharePoint Designer Workflow there is only one field to set for both values.

I was creating a custom 'My favorites'  list when this problem came up. I wanted to create a simple workflow in a document library where users could opt to create links to certain documents in the favorites list by running the workflow for each of these items.

The central part of the document library workflow is of course the create item action. The action is simply set to create an item in the favorites list that sets the item's URL field. I created a workflow variable where I define the string that will hold both the link's display name and URL. Thus the first action of the workflow is to update the variable.

In the string builder dialog simply put together: [%Current Item:URL%], [%Current Item:Name%]. The URL and display name is thus separated by a comma and space. Both of these are important.

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.

Beware! Business Data Connectivity is case sensitive for database field names

An unforeseen problem with a major impact was uncovered the other day. We have set up an external content type querying an SQL server database table. During a simple change to this table it was recreated with upper case field names, where it earlier had a mix of lower and upper.

This broke the External content types connected to this table. No external list data could be displayed, no external data columns in lists or libraries could be updated, and no actions (like view profile page) would function.

In SharePoint Designer configuration of operations (here the Read List Operation) it is obvious that the original configuration is not able to update with the 'new' column names. Both new and old formats are visible, but the original configurations are locked in and unavailable.


The only way to solve this problem was to recreate the table with the original column name formats. After doing so everything went back to normal.

Henning

No data displayed in external list due to wildcard filter lacking default value

I have been doing quite a bit of External Content Type work lately. One small thing that threw me off was that though everything seemed OK with the query and setup, my external list would not display data.

The simple solution in my case was that my Wildcard filter set up for the Read List Action needed a '%' in the Default value field under Filter Parameters Configuration. This for a SQL Server connection.

Group list items by first letter in item name in an A-Z list view

A really simple solution when a client needed an alphabetically displayed list of items. This was to be an A-Z list of useful tips for new employees.

I solved this by adding a calculated column to my list with the formula to extract just the first letter of each item's title like so: =LEFT(Title,LEN(1)).

Then I created a view with the Group By option set to my new column.

Simple but effective!

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.

SharePoint permission groups disappear when sites are deleted

This one really bugged us for a while. Seemingly at random some of our permission groups suddenly disappeared into thin air, leaving lots of users unable to access their SharePoint sites and content.

After doing some research we found that in every instance this was related to groups originally created for sites that were deleted some time ago. These permission groups at first seem to live on happily even after site deletion, but reusing these groups for new sites will come back and kick you hard.

The fact is that when you delete a site, the site lives on in the Recycle bin for 30 days (default setting), hence the site is not deleted but rather marked for deletion. And actually so are the permission groups originally created for the site during site creation. (These groups are only created if you do not opt for permission inheritance, of course.)

The big draw back is that there is no way to identify that these groups in fact are marked for deletion!

So, guess what happens then after the Recycle bin period is over and the cleanup job does what it's supposed to do? The site and permission groups are gone.

So. Best practice is to not keep using these permission groups, but rather always create new permission groups when creating new sites that need dedicated permissions. Or create permission groups outside of the site creation wizard and hook these up to your sites manually.

:-) Henning

Easy fix of slow webdav connections to SharePoint using IE on Windows 7

For some time I have been extremely annoyed by how slow it is to work with documents and files in SharePoint when I'm sitting outside of my office, logging into our VPN.

The problem is related to the Webdav (Web Document Authoring and Versioning) method that is being used, and apparently a setting in Internet Explorer related to this.

To fix the problem: in IE go into Tools -> Internet Options ->  Connections -> LAN Settings and uncheck the Automatically detect settings check box.

Instant fix!

Term store management link missing from site administration

This typically happens when you create a root site of a site collection from the blank site template

Run 2010 Management Shell as admin and execute the following Powershell command:

Enable-SPFeature -id “73EF14B1-13A9-416b-A9B5-ECECA2B0604C” -Url https://your/siteurl/here

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!

Adding a custom CSS file to your SharePoint 2010 master page

I have been meaning to blog for quite some time, but have been thinking that it will take way too much time. But let me start simple by documenting the single most impactfull change one can do to the visual side of SharePoint, namely change the master page by adding your own CSS file.

To get it to load correctly and in the right order to the native CSS files used by SharePoint you have to do it like this.

<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/myCustomStyles/myCustomSheet.css %>" After="corev4.css" runat="server"/>

Place the line right before the closing </HEAD> tag and you'll be off to a good start.