Google Analytics

Monday, November 8, 2010

Search Core Results Web Part Doesn't Display Managed Property

Everything is set up right.  I've followed articles like this, or maybe this.  I've full crawled a million times, but I still can't get my managed property to display in the search core results web part.

First, double check search is crawling your content properly.  Go to Search administration -> Metadata properties and click the name of your metadata property.  There's a section here labeled 'Content using this property'.  'Number of items found using this property' obviously should not be zero.  If it is, take a look your managed property configurations.  Also, confirm you've actually set the value somewhere in your site and, if in a publishing environment, make sure everything is published and approved.

Second, go to the search box in the site and search for MetadataField:AValueYouKnowExists.  The results should be as expected.  Items with your MetadataField = AValueYouKnowExists should appear in the results.

Lastly, double check the Search Core Results XSLT.  Make sure you've got the proper <Column Name="MetadataField"/> tag.  Also, make sure you're using the right metadata property name in the <xsl:value-of> tag.  This tag is case sensitive.  If you don't get the case right, it's not going to work.  The easiest way to check the case is to edit the Search Core Results web part and put <xmp><xsl:copy-of select="*"/></xmp> into the section labeled <xsl:template match="Result">.  This is going to display all the XML nodes and the values contained in the results.  Refresh your MetadataField:AValueYouKnowExists search and look for your metadata property.

Saturday, October 23, 2010

Absolute Left-hand Navigation in Page Layouts

I've chosen this topic because when I first received the requirement for this, I thought it'd be tough or at the very least, messy.  It turned out to be extremely simple and clean.

Business owner, "When I'm navigating my particular sub-site, I always want the left-hand navigation to begin with the first node in my sub-site.  This should always be the case no matter how deep I get in my sub-site."

Example Site Structure:
Root Site Collection
   Busines Owner's Sub-Site
   (Nav should begin here no matter which page we're actually on)
      Pages
      A Lower Sub-Site
         Pages
         An Even Lower Sub-Site
            Pages

To fulfill this requirement, it's merely a matter of configuring your SiteMapDataSource (or PortalSiteMapDataSource) properly.  We need to key on two properties, StartFromCurrentNode and StartingNodeOffset.

In this case, we'd want StartFromCurrentNode = false and StartingNodeOffset = 1.  The tells our SiteMapDataSource to always start at the Root Site Collection node then offset one node down.

The only downfall I can see here is you're going to have to train the business owner to use the right page layouts, but they have probably already asked for special branding anyway.

References:
SiteMapDataSource.StartFromCurrentNode
SiteMapDataSource.StartingNodeOffset

Wednesday, October 20, 2010

OWSTIMER, Give Up Your Cache

Recently, we had some struggles surrounding SharePoint solution deployment.  In our farm (2 WFEs, 1 App, 1 DB), one of the WFEs consistently kept throwing errors when deploying my solution.


Always...two deployed fine, one failed.  Strangely, the failed server wasn't always the same.  At times, it even exhibited a sort of round-robin behavior.  First 4, next attempt 5, next attempt 3, then back to 4.

I was not able to replicate this in my dev environment until, instead of deploying the solution via the Central Admin Application, I deployed it using the stsadm -o deploysolution command.

The stsadm command clearly states "Timer job successfully created," but upon checking the Central Admin Application for status I found "Error".  This pushed me to investigate the Windows SharePoint Services Timer service and led me to believe it was incorrectly caching something.

I followed the steps highlighted in the resource articles and magic, it's fixed.

For the record, I did delete the cache.ini file without problems.  Also, depending on if you're using Server 2003 or 2008, the cache files are in different places.  Just use the %ALLUSERSPROFILE% token in the address bar of Windows Explorer and you should be good to go after that (e.g. %ALLUSERSPROFILE%\Microsoft\SharePoint\Config).

References:
Clearing the Sharepoint configuration cache (Joris Poelmans)
Clearing the SharePoint Configuration Cache (Joe Rodgers)

Monday, October 11, 2010

Tired of Logging into Firefox?

Typing in my username and password all day long is tiresome.  IE offers nice NTLM integrated authetication functionality using Local Internet and Trusted Sites settings.  Wouldn't it be nice if you could do that with Firefox?

  • Open Firefox.
  • In the address bar, navigate to 'about:config'.
  • Filter the resulting list by 'network.automatic-ntlm-auth.trusted-uris'.
  • Change the value of this variable to .company.com.

References:

Tuesday, October 5, 2010

Remove Default SharePoint Web Part CSS

**UPDATE: See this revision.

It’s always been a struggle for me to style a web part in SharePoint because of the default Microsoft classes that get added (i.e. .ms-WPBody a:link, .ms-WPBody a:visited, blah, blah, blah).  These stylings are annoying and difficult to override because they’re directly on the web part and sometimes replace general site CSS.
Well…just turn them off.

For the DataViewWebPart...
<SharePoint:DataFormWebPart runat=”server” NoDefaultStyle=”true” …>
</SharePoint:DataFormWebPart>
(This also works for the CoreResultsWebPart as it’s essentially just a DVWP).

If you're creating your own web part...
public class NoCssWebPart : WebPart
{
      public NoCssWebPart()
     {
          this.UseDefaultStyles = false;
     }
}

References: