Article Categories
Archives
Post Categories
  Jump to Information for:
Search:  

Monday, November 10, 2008

I recently discovered that your custom master page may affect the Gantt view of a SharePoint list.  I have seen the colored task bars extend past the framed container of the chart when a custom master page and CSS is applied to the site.  If this happens to you, you can try the following:

  • Systematically strip out the CSS and HTML to identify what code is causing the problem. Be sure to make backups of your files first.
  • Adjust the DOCTYPE tag that you are using. When this happened to me, I had to go way back and use the following DOCTYPE to get the Gantt view to show correctly:  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

And finally, add this on to your list of items to test while developing custom master pages for SharePoint!

If you are working with SharePoint in Firefox, the top toolbar (Welcome menu, My Site, My Links) may not display correctly. Click here for a screenshot.

Add this to your CSS to correct this problem:

.ms-globallinks {
    white-space:nowrap
}

This works in Firefox and won't wreck IE. 

Monday, September 29, 2008

I made an update to my Base Master Page today that moved the PlaceHolderLeftNavBarTop content placeholder from the hidden ASP Panel at the bottom of the file to an appropriate place in the left navigation area.

The content page (\12\Templates\SiteTemplates\SPSMSITE\default.aspx) that controls the profile/public page of My Sites adds the profile picture of the user to the left navigation bar via the PlaceHolderLeftNavBarTop content control.   To show this profile picture in your custom mater page, you need to include this content placeholder in your code.

Wednesday, August 27, 2008

This has nothing to do with SharePoint.  :-)  I found this article rather interesting... it is about designers getting back to doing things with their hands in this uber electronic, hands on activity depraved world.

Digital Designers Rediscover Their Hands

It struck particularly close to home with me, as I have picked up a new creative hobby and totally banned using computers in any way.  Good stuff for the right side of your brain.  The object of the article are designers from Adobe, which I also found interesting and inspiring.  Maybe what SharePoint needs is a heavy dose of wood shop class!

Thursday, August 21, 2008

User Interface Engineering has posted an article about breadcrumbs, and why they feel that breadcrumbs are a design cop-out.  It is a good read, especially for people using SharePoint for external facing sites.

» Design Cop-out #2: Breadcrumbs

Personally, I only utilize page breadcrumbs when working with administering lists and settings.  The breadcrumb provides a quick way back to list screens and other setting screens where otherwise no navigation is provided.  For that purpose I think they can be useful.  The article brings up some valid points on whether or not to use breadcrumbs at all.

A common request is to alter the default look of the search input and button area to something that better matches a design or fits better in space that is available.  When working with the default search, you are limited to the CSS classes provided to you and the layout that ships with SharePoint.  It is possible to create your own search display by deploying a Feature.  Note I am not referring to search results, just the search box area available on most SharePoint pages, generally located in the header section.

MSDN documents this process and the code they provide will nearly work as is.   There are two changes that need to be done to their code in order for the Feature to function on your web site. Below are the changes and a few other tips and resources to help you.

*** NOTE:  This is to modify the basic search for WSS.  MOSS uses another Feature for search (OsearchEnhancedFeature) and if you do the following actions, your custom scopes will not appear in the drop down box. If you are not using custom scopes, or if you don't want or use "All Sites" and "People" search scopes, you can use this method to adjust your MOSS search display. ***

  1. Open up the MSDN article.
  2. Complete step 1 and 2.
    1. Note the HIDDEN property and value in the Feature tag.  Make sure you change the HIDDEN value to FALSE.  We need to show the Feature.  :-) Thanks to AC for this tip. This is not required, but you will more than likely want to show this Feature in your site Features list.
    2. Note the SCOPE property and value. This article has you set the Feature's scope to WEB, which is fine.  But you will have to activate this Feature for every site (and sub site) that needs to use the new search area. Depending on your setup, this may not be ideal.  Other options for this value are Farm, WebApplication, and Site. The first two are self explanatory, and Site means site collection.  Web means a single web site.
  3. Complete step 3.
    1. Note the sequence value.  For WSS, 99 will work.  For MOSS, you need to lower the value to 20. Thanks to AC's book, Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007 (Wrox Programmer to Programmer) for this tip.
    2. Note the two properties the article has you add in.  For a full list of possible properties you can use here, check out the SearchBoxEx Members and look under Public Properties.
  4. Complete step 4.  Note that you can name the new file whatever you like, and store it in a sub folder.  If you place the file in  sub folder, you can easily identify your custom ASCX files and they won't get lost in the jumble of the default SharePoint files.
  5. Step 5 is up to you.  If you want to do the changes just like the article, follow this step. Otherwise, in your custom ASCX file, make any adjustments you like including dropping the table, using DIVs, adding custom text and images, etc.  You can also specify custom CSS classes.  Store your CSS properties in your site style sheet.
  6. Complete steps 6 and 7.  Note, if you set the scope to Farm, you don't have to activate the Feature. That happens automatically when you install the Feature.

That's it!  In a relatively short period of time you can create a custom search display for your site.

Alternatively, John Ross has blogged about another method using JavaScript. Check out his post here.

I have found a few more resources online, here they are in case you want to learn/do more:
Project to customize the small search control in SharePoint 2007
Redirect Contextual Search Results to Search Centre Results Page
Search Results Page may be different per Search Scope

Wednesday, August 13, 2008

I don't think I am alone when I say "I hate the page level breadcrumb in SharePoint".  While dead useful for users, it becomes a bit nightmarish for devigners. For this post I am going to ignore the Global Breadcrumb that appears in the upper left of a SharePoint site by default, because honestly most people hide it and it doesn't cause near the heartburn as the page level breadcrumb.

Some background....   the page level breadcrumb (from this point forward just called breadcrumb) is included on the master page.  It is wrapped in a content placeholder.  So the master page is providing the default content for that content placeholder.  Page layouts have the power to trump that default content and specify their own content for any content placeholder.  Including not specifying any content at all, which effectively wipes out whatever is in the master page and displays nothing on the screen.

Some of the default page layouts in a publishing site move or hide the breadcrumb.  What you set in your master page won't necessarily be what you get as you move from page to page in your site.  You can avoid this completely by using your own master page and your own page layouts.   If you choose not to use only custom page layouts, you will probably need to tweak the OOTB page layouts to get the breadcrumb to show how you want it across the entire site.

You may be tempted to stick the breadcrumb code in the master page and not wrap a content placeholder around it.  I would recommend against this, as you are stopping the ability to hide the breadcrumb on choice pages, like the home page.  

Here is a breakdown of what the OOTB page layouts do in regard to the breadcrumb. I color coded the rows to show which page layouts do the same thing/use the same code:

 

AdvancedSearchLayout.aspx Breaks the inheritance from the master page. Specifies unique code that does not include the breadcrumb. 
ArticleLeft.aspx Breaks inheritance from the master page. Specifies breadcrumb code that includes a DIV tag with a class of "breadcrumb".
ArticleLinks.aspx
ArticleRight.aspx
BlankWebPartPage.aspx
DefaultLayout.aspx Breaks the inheritance from the master page.  Does not specify any code in the breadcrumb content placeholder, thus blanking out the breadcrumb set in the master.  Sets up the breadcrumb in a table in the PlaceHolderMain content placeholder.  The table cell uses a CSS class of "ms-pagebreadcrumb".
NewsHomeLayout.aspx
PageFromDocLayout.aspx Breaks inheritance from the master page. Specifies breadcrumb code that includes a DIV tag with a class of "breadcrumb". 
PageLayoutTemplate.aspx N/A  - This is used as the starting point to create new page layout files.  
RedirectPageLayout.aspx N/A  - This is used to redirect pages.
ReportCenterLayout.aspx Breaks the inheritance from the master page.  Does not specify any code in the breadcrumb content placeholder, thus blanking out the breadcrumb set in the master.  Sets up the breadcrumb in a table in the PlaceHolderMain content placeholder.  The table cell uses a CSS class of "ms-pagebreadcrumb".
SearchMain.aspx Breaks the inheritance from the master page. Specifies unique code that does not include the breadcrumb. 
SearchResults.aspx
TabViewPageLayout.aspx Breaks inheritance from the master page. Specifies breadcrumb code that includes a DIV tag with a class of "breadcrumb".   
VariationRootPageLayout.aspx   N/A  - This is used when provisioning a site for variations. More info.
Welcomelayout2.aspx Breaks inheritance from the master page. Specifies breadcrumb code that includes a DIV tag with a class of "breadcrumb". 
WelcomeLinks.aspx Puts the breadcrumb code inside of the PlaceHolderMain content placeholder. Wraps the breadcrumb in a DIV tag with the CSS classes of "ms-pagebreadcrumb" and "removeMargins". Note that it does not break inheritance for the breadcrumb content placeholder from the master page.  
WelcomeSplash.aspx Breaks inheritance from the master page. Does not specify any code, thus blanking out the breadcrumb from the web page.
WelcomeTOC.aspx Puts the breadcrumb code inside of the PlaceHolderMain content placeholder. Wraps the breadcrumb in a DIV tag with the CSS classes of "ms-pagebreadcrumb" and "removeMargins". Note that it does not break inheritance for the breadcrumb content placeholder from the master page.  

As you can see, there is a lot of variety going on with the OOTB page layouts. It is possible to modify the styles used in the various breadcrumb instances to all look nearly alike, giving you a uniform look and feel for breadcrumbs across your site. You just need to specify the same styles for "ms-breadcrumb" and "breadcrumb". Or you can choose to go in and alter the page layouts that you need to in order to create uniformity.   Either route, just test the dickens out of it to make sure no pages show up odd.

If you are working only with WSS sites, note that default.aspx (used for the home page) breaks the inheritance from the master page and does not specify any code, thus blanking out the breadcrumb from the web page. Most other ASPX files that WSS sites use do not specify anything, so they inherit the breadcrumb from the master.

The next challenge with the breadcrumb is the site map provider it uses.  There are several available in SharePoint, and two that are used predominantly for WSS and MOSS sites in the breadcrumb.   The problem is the WSS one is great for lists and libraries, and the MOSS one is great for publishing pages.  But they each are not great for the other. 

Breadcrumb with site map provider best for WSS:
<asp:SiteMapPath SiteMapProvider="SPContentMapProvider" id="ContentMap" SkipLinkText="" NodeStyle-CssClass="ms-sitemapdirectional" runat="server"/>

Breadcrumb with site map provider best for MOSS (publishing sites):
<asp:SiteMapPath ID="siteMapPath" Runat="server" SiteMapProvider="CurrentNavSiteMapProviderNoEncode" RenderCurrentNodeAsLink="false" CurrentNodeStyle-CssClass="breadcrumbCurrent" NodeStyle-CssClass="ms-sitemapdirectional"/>

The main issue with the WSS site map provider is it will show directories you don't want it to (mainly the Pages library) in the breadcrumb, and on some pages it will show ".aspx" on the end of the page name. The MOSS site map provider is more graceful, it just doesn't show the list or library name in the breadcrumb.

This image shows examples of both site map providers being used on the same pages and the differing results:  view image. Please note that for these samples, I directly added the breadcrumb code to the master page, outside of a content placeholder.  That is why it appears on all pages.

So which one should you use?  It really depends on the type of site(s) you are running and what you personally want to use. Luckily it doesn't end there.  There are a host of resources for how to modify and use the breadcrumb:

Hope this helps!

Randy Drisgill came across a great challenge and weird issue with SharePoint in regards to disabling themes on custom master pages.  I wanted to expand a bit more on what he has posted about.

Themes can wreck havoc on master pages since by default theme styles are called after regular SharePoint styles.  Depending on your changes, themes may leak through via changing styles you did not, or if you used the Alternate CSS property in Master Page Settings to call your custom styles. The Alternate CSS is called along with those regular SharePoint styles (via the CssLink tag in your master page) and the theme is called after that.

When you have a custom master page, the master page is stored in the content database.  When you add a theme, SharePoint adds a meta tag to the master page right before the closing HEAD tag, thus rendering any styles you specified as defenseless against the applied theme.  The meta tag looks like this:

<meta name="Microsoft Theme" content="ThemeName 1011, default" />

If your design requirements include creating a matching theme for your site, you can create the theme and master page in tandem so you don't have conflicting styles.  But if you have to create the theme after the fact, you will spend extra time fixing issues the theme causes for your site with the custom master page.  And if you do create them in tandem, your theme may cause you extra grief, and you may want to follow this solution anyways to avoid that.

If the theme is only there to brand application screens (_layouts) you can choose to remove the Theme tag from the master page, then the theme will only apply on application screens and your custom master page and site will not be affected.  Doing this will work, and will bring you to the issue that Randy discovered.  Randy mentions using a Feature to deploy the master page to the server, and I certainly agree with that recommendation.  But if that is not feasible for your situation, you have some options.

First, the order of how you do things.  If your theme causes issues:

  1. Open the custom master page in SharePoint Designer (SPD).
  2. Go to the site and apply the theme.
  3. Return to the master page in SPD and remove the theme tag (<SharePoint:Theme runat="server"/>).   If you have been messing with applying themes, go ahead and check for a theme meta tag right before the closing HEAD tag.   If you find one, remove it.   
  4. Save the master page.
  5. Go the site and check it out, you should have themed application screens and non-themed site pages.

If you have to mess around and try out different themes, be sure to open up your custom master page first in SPD.  As you mess around your site pages will be affected.  Once you settle on a theme or finish your testing, go back to SPD and save the master page.  No need to make any changes.  SPD will re-save the clean version of the master page in the content database and wipe out any meta tags SharePoint added for the theme.

Going forward you will still face this potential issue if anyone has rights to update the theme.  You can avoid this by removing the other themes from the theme picker screen (if you need help with this, check out this section of this post and instead of adding template blocks, remove all the ones you don't want).  This works because SharePoint will only add the meta tag if you change a theme.  Once set and no options for change, your master page will be preserved.

If this isn't an option for you, really restrict who has access to change themes, go back and make your theme compatible with your master page, or deal with what may happen when the theme changes.  Sorry I don't have a better answer. It may be possible to create a Feature that requires moderation for theme changes.   

In case you are wondering, you can move the Theme tag in the master page above the CssLink tag, but that will only help you stop a theme from changing your stuff if you remove the meta tag SharePoint places in the master page.  Moving the theme tag doesn't bypass this issue.

My ending advice would be, while in development keep your master page open in SPD before and while you mess with themes so any saves you do will remove that meta tag.  And if you can, use a Feature to deploy custom master pages on production servers.

Wednesday, August 06, 2008

I added Blog and Wiki styles to my SharePoint 2007 CSS Reference Chart.

Friday, July 25, 2008

This is small, but gets me all of the time.   When you are working with the Global Navigation (a.k.a. Top Nav Bar) in SharePoint and you are using 2 levels of flyout menus, the arrow that appears for the second level of items may show the wrong background color when you hover over the item or arrow.

As you start to alter the various colors and styles in the menu code, the background color behind the arrow does not reflect your changes or seem to pick up any styles from parent elements. Here is an example of this happening.

By default, the SharePoint menu code in the master page manually specifies a color for this hover effect:

<SharePoint:AspMenu ..... lots of properties....   DynamicHoverStyle-BackColor="#CBE3F0"  >

You don't have to replace the color or specify a style, just delete the property and your colors will shine through.

<SharePoint:AspMenu ..... lots of properties.....  >

This does require edits to the master page, there is no CSS class specified, so you can't change this with CSS only.

 


Copyright © 2005-2008. Heather Solomon.
Site design by Heather Solomon

Blog Stats:
Posts - 377
Stories - 38
Comments - 1556
Trackbacks - 182