Dedicated to development, configuration, and tips and tricks for both WSS 3.0 and MOSS

Posted by Aaron Varga on Thursday, 19 Feb 2009 01:51

If you’ve ever had the need to hide the first tab in your SharePoint site, you know it’s not as easy as it sounds.  Luckily with a little CSS finesse, you can.  Let’s take a look at a typical SharePoint site:

image


As you know, you can go to Site Settings > Navigation, and modify the nodes that appear on both the Global Navigation (top link bar), and the Current Navigation (quick launch).  However, there’s nothing there that allows you to change the first tab!

image


Using the super-secret method of looking at the page’s source, you can find the actual HTML which renders the first node, and as you can see, it has an ID of zz1_TopNavigationMenun0:

image


Simply add the following CSS to your master page or to a CSS file your master page is referencing:

<style type="text/css">
    #zz1_TopNavigationMenun0 {
        display: none }
</style>

 

Poof!  The first tab is gone!

image

Posted by Brian LaSitis on Wednesday, 7 Jan 2009 03:01

An ever elusive point about SharePoint 2007 is its support for consistent site navigation throughout a web application.  Out of the box, SharePoint does a great job at providing customizable navigation options for within a site collections, allowing sub-sites to inherit the navigation as necessary, and a consistent structure is available to users navigating throughout that site collection without a lot of effort.  That said, most SharePoint implementations incorporate several site collections, to employ a clean design and apply best practices.  This means that while navigation within each of these site collections can be customized as seen fit, nothing is provided out of the box to incorporate the navigation from each site collection into a common structure.

Fortunately, with a little bit of development effort, a solution to this problem is achievable, and three options are possible.  The options described go from least custom development effort to most, and each has its own positive & negative points.

1) The first option involves the use of an ASP.NET XML Site Map file.  By leveraging a capability that has been built into ASP.NET 2.0, you can create your own site map file that contains links to each of your site collections, and then integrate this into SharePoint.  The integration of this into SharePoint requires the actual XML site map file itself, as well as some customizations to the web.config file within the web application's IIS web site root folder, and customizations to the master page within each site collection to enable the site map file to be used on the page.  The biggest caveat or limitation with this approach is that the XML site map file must be maintained independently from the SharePoint content, and therefore any time a new site collection is created, a manual update to the XML site map file is required.  Additionally, using this approach, no support for security trimming of the navigation links is available.

2)  The second option is an extension of the first described above, namely adding support for security trimming.  The ASP.NET site map file format actually supports the assignment of roles to each site map node, however the standard site map provider classes do not use this data.  Because of this, to leverage the information specified in the roles attribute of a site map node, a custom site map provider must be developed.  Fortunately, since this is just an extension of the standard XmlSiteMapProvider class, simple inheritance buys you most of the implementation, and the only real "work" to do is to provide an implementation of the IsAccessibleToUser function, basically to determine if a given site map node is accessible or not to the current user.  Assuming you have a method to do this, it is a fairly trivial task to complete -- with a site using Windows Integrated Authentication, LDAP would be used to check group membership, and for a custom FBA site, you would need to manipulate the MembershipProvider or RoleProvider objects used by your site to perform these checks.

3) The third and final option for implementing a common navigation across all site collections is to actually create a custom site map provider that uses the SharePoint object model to walk the site collections within the web application and actually return the data by overriding the required methods in the abstract SiteMapProvider class.  This option has the advantage of having new sites as they are created actually showing up within the navigation without any additional steps required, however, it does have one limitation in that all of the links shown within the SharePoint navigation structure must be actual content within SharePoint itself (e.g. a site collection root or sub-site), as there is no way to indicate to SharePoint where additional external links should be added in using this method.  This method also has the negative aspect that it requires the most custom development effort of the three described.