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. Exception occurred. (Exception from HRESULT: 0×80020009 (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.

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]

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.

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.

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.

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.