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
“Often when you think you’re at the end of something, you’re at the beginning of something else.” – Fred Rogers
Google Analytics
Saturday, October 23, 2010
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)
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?
References:
- 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.
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:
Subscribe to:
Posts (Atom)