Display filename instead of document title in SharePoint search

My employer has been using SharePoint for a number of years now, and it’s recently come to light that people haven’t always been putting meaningful information in the Document Title field. It seems that if this field is left blank, it will default to the document filename, but a lot of our documents have incorrect titles. e.g. if they have been based on a template or another document.

Clearly the best solution is to educate users to use the Title field properly for newly-created documents (see Title vs Name), and also to update all existing documents, but it’s a big task and for now we have opted for the”quick fix” of showing the document filename in search results. Here’s how you do it:

  • Ensure that the IsDocument managed property is set for use within scopes:
    • Browse to Central Administration
    • Click on your Shared Service Provider
    • Click Search settings
    • Click Metadata property mappings
    • Find the IsDocument property and set Use in scope to True
    • Click OK
  • Edit the page and modify the Search Core web part
  • Under Results Query Options, edit the Selected Columns property to include Filename:
    <Column Name=”Filename”/>
    (it doesn’t matter where as long as it is between <Columns> and </Columns>, and obviously not halfway through another <Column> tag)
  • Find the following line (it should be in the Result template):
    <xsl:variable name=”id” select=”id”/>
  • Underneath it, add the following two lines:
    <xsl:variable name=”filename” select=”filename”/>
    <xsl:variable name=”isdocument” select=”isdocument”/>
  • A few lines down, replace the code starting with <span class=”srch-Title”> and ending in</span> with the following:
    <span class=”srch-Title”>
    <a href=”{$url}” id=”{concat(‘CSR_’,$id)}” title=”{$url}”>
    <xsl:if test=”$isdocument &#61; 1″>
    <xsl:value-of select=”filename”/>
    </xsl:if>
    <xsl:if test=”$isdocument &#61; 0″>
    <xsl:choose>
    <xsl:when test=”hithighlightedproperties/HHTitle[. != ”]”>
    <xsl:call-template name=”HitHighlighting”>
    <xsl:with-param name=”hh” select=”hithighlightedproperties/HHTitle” />
    </xsl:call-template>
    </xsl:when>
    <xsl:otherwise><xsl:value-of select=”title”/></xsl:otherwise>
    </xsl:choose>
    </xsl:if>
    </a>
    <br/>
    </span>

I found this tip on the TechNet forums, although it didn’t work as-is because the author had forgotten to declare the isdocument variable. It has been tested in MOSS 2007 but will possibly also work in SharePoint 2010. If desired, you could easily tweak the XSL above to show the document title as well as the filename.

There’s no easy way of changing the OSSSearchResults.aspx page that appears when you do a “This Site” search, and even if you do, it’s unsupported and any changes will most likely be lost next time you install a MOSS service pack. If you have ISAPI_Rewrite installed, as we do, you can easily redirect site searches to the Search Center using this line:

RewriteRule ^(.*)OSSSearchResults.aspx(.*)$ /SearchCenter/Pages/results.aspx$2 [I,L,RP]

“Cannot save the property settings for this Web Part” error when using SmartPart in SharePoint

I recently deployed a custom user control using SmartPart on SharePoint 2007, and although everything else seemed to work fine, I came across the following error when trying to edit the properties (in my case, the chrome type and width):

Cannot save the property settings for this Web Part. Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))

I managed to resolve this, thanks to an MSDN forum post, by changing one of my lines of code:

using (SPSite oSiteCollection = SPContext.Current.Site)

to the slightly more long-winded:

using (SPSite oSiteCollection = new SPSite(SPContext.Current.Site.ID))

I’m not sure why using SPContext.Current.Site directly (versus creating a new SPSite object) causes this behaviour, but at least it’s a simple fix.

Using ISAPI Rewrite to redirect domain.com to www.domain.com

My employer’s SharePoint-powered external website – which I look after – uses ISAPI Rewrite to provide “friendly” URLs for certain pages, and also to redirect old URLs to their new locations. Coming from a LAMP background, this is great for me as it basically works the same as Apache’s mod_rewrite.

Previously the website responded to requests for both domain.com and www.domain.com, which is not ideal. SEO best practice is to either redirect the non-WWW version to the WWW version, or vice-versa. In my case, www.domain.com is the preferred format, so I’m using the following rule:

### Redirect domain.com to www.domain.com
RewriteCond Host: ^domain\.com
RewriteRule (.*) http\://www\.domain\.com$1 [I,RP]

If you want to do the opposite, you’ll need this one:

### Redirect www.domain.com to domain.com
RewriteCond Host: ^www\.domain\.com
RewriteRule (.*) http\://domain\.com$1 [I,RP]

SharePoint and getElementById()

I’ve just found out that using JavaScript’s getElementById() function doesn’t quite work as expected when dealing with controls on SharePoint pages. This is because SharePoint uses its own identifiers, so TextBox1 becomes something like ctl00$ctl00$g_3f6d90e4_335b_467c_a53f_6ae00bca6b63$ctl00$TextBox1.

Fortunately there’s a simple solution – instead of the following (which will cause an “Object required” JavaScript error):

document.getElementById("TextBox1");

you need to use this, which will insert the correct full ID for the element and thus work correctly:

document.getElementById("< %=TextBox1.ClientID%>");

It gets a bit more complicated when using nested controls, which is explained in this post by Eric Shupps.

How to check whether a SharePoint user is in a particular group

Here’s a quick function I wrote to check whether a user is a member of a particular SharePoint group:

private bool IsMemberOf(string groupName)
{
    SPUser user = SPContext.Current.Web.CurrentUser;

    try
    {
        if (user.Groups[groupName] != null)
            return true;
        else
            return false;
    }
    catch
    {
        return false;
    }
}

The try-catch is required as – somewhat counter-intuitively – SharePoint seems to throw a “Group not found” error if the user is not a member of the group.

How to set SharePoint page title programmatically

I’ve spent some time today trying to figure out how to set the title of a SharePoint page from my own code. As blogger Michael Becker rightly points out, you can’t simply set Page.Title.

The correct solution, as provided by Michael, is illustrated in this example C# code:

// Get a reference to the appropriate Content Placeholder
ContentPlaceHolder contentPlaceHolder = (ContentPlaceHolder) 
                       Page.Master.FindControl("PlaceHolderPageTitle");

// Clear out anything that SharePoint might have put in it already
contentPlaceHolder.Controls.Clear();

// Put your content in
LiteralControl literalControl = new LiteralControl();
literalControl.Text = "Your text goes here";
contentPlaceHolder.Controls.Add(literalControl);

Happily this even works when you “cheat” by hosting an ASP.NET user control within a SmartPart, as opposed to creating a bona fide Web Part.

Deploy ASP.NET web user controls on SharePoint using SmartPart

Today I’ve been playing with Return of SmartPart 1.3,  a shim which allows you to create SharePoint 2007 web parts using Web User Controls (ASCX files) created by Visual Studio/Visual Web Developer.

This is probably the least painful way for C#/VB.NET developers to delve into web part building without having to worry too much about the intricacies of the SharePoint platform.

Complete with setup wizard, comprehensive user guide and sample user controls, it’s a snap to get running, although you will need access to your SharePoint server both to install the SmartPart and any custom user controls. It also optionally supports AJAX controls, after installing Microsoft’s ASP.NET AJAX extensions.

There’s no need to use strong naming or even compile your controls – just drop the .ascx (and .ascx.cs/.vb, if necessary) files into your usercontrols directory and you’re good to go.