SharePoint 2007 – Branding Your application.master Page

Most SharePoint administrators and developers are aware of the techniques for customizing the master page for a SharePoint site, so I am not going to go into detail on this topic.  However, I do want to share with you any easy technique I found for customizing the administrative pages on a SharePoint using the application.master file.

A quick background on administrative pages vs. regular SharePoint pages:  Most content pages that you create within a SharePoint site are stored within the content database and are easily styled using a custom master page and style sheet specified on the site settings page.  These pages typically consist of web part pages, home pages, and other pages you create to display SharePoint content, these pages inherit the master page and CSS settings that you specify in the site settings of your SharePoint site.

The other types of pages that you see within SharePoint pages are called “administrative pages” or “application pages”.  Those pages are supplied by Microsoft as part of the SharePoint installation and are used to configure and administer your SharePoint site, these pages are NOT stored in the content database and are instead stored on the file system in the _Layouts directory (typically this is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts ).   Another important difference between these two types of pages is that all the styling of administrative pages is specified in a single master page named “application.master” which is stored on the file system in the _Layouts folder. 

One very important note about the styling of administrative pages using the application.master is that each SharePoint farm can only have one application.master file in the _Layouts folder, which typically means that ALL your administrative pages across your entire SharePoint farm must share the same styling.  This can present a design challenge if you are a SharePoint administrator and you are asked to have different styling for different sites and site collections within the same SharePoint farm AND you need the administrative pages to be styled consistently with those sites and site collections.  In a future post I will present some options on how to address this limitation.

Back to the easy technique for branding (styling) your application.master page.  Standard master pages and the application.master file are generally the same but do have some very slight differences.  You cannot simply copy your regular master page content into the application.master file and expect everything in SharePoint to work perfectly, they are not 100% compatible.  However, you can take your regular master page and tweak it (with little effort) to use as your application.master file.  Below is an outline of the “tweaks” that need to be made

Tweak 1.  Application.master files should not contain the delegate control for the SmallSearchInputBox.  You can simply remove the following reference from your master page:

                        <SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox"/>

Tweak 2.  Application.master should also contain the following content placeholder tags, several pages within the _Layouts folder rely on these tags:

                        <asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr" runat="server" />
                        <asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr2" runat="server" />

Thus far I’ve only found these two tweaks, or changes, needs to be made to a master page in order to use it as your application.master page.  If you find that there are other required tweaks, please pass those along to me so that I can update my post.

SharePoint 2007 – Branding Your application.master Page

Most SharePoint administrators and developers are aware of the techniques for customizing the master page for a SharePoint site, so I am not going to go into detail on this topic.  However, I do want to share with you any easy technique I found for customizing the administrative pages on a SharePoint using the application.master file.

A quick background on administrative pages vs. regular SharePoint pages:  Most content pages that you create within a SharePoint site are stored within the content database and are easily styled using a custom master page and style sheet specified on the site settings page.  These pages typically consist of web part pages, home pages, and other pages you create to display SharePoint content, these pages inherit the master page and CSS settings that you specify in the site settings of your SharePoint site.

The other types of pages that you see within SharePoint pages are called “administrative pages” or “application pages”.  Those pages are supplied by Microsoft as part of the SharePoint installation and are used to configure and administer your SharePoint site, these pages are NOT stored in the content database and are instead stored on the file system in the _Layouts directory (typically this is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts ).   Another important difference between these two types of pages is that all the styling of administrative pages is specified in a single master page named “application.master” which is stored on the file system in the _Layouts folder. 

One very important note about the styling of administrative pages using the application.master is that each SharePoint farm can only have one application.master file in the _Layouts folder, which typically means that ALL your administrative pages across your entire SharePoint farm must share the same styling.  This can present a design challenge if you are a SharePoint administrator and you are asked to have different styling for different sites and site collections within the same SharePoint farm AND you need the administrative pages to be styled consistently with those sites and site collections.  In a future post I will present some options on how to address this limitation.

Back to the easy technique for branding (styling) your application.master page.  Standard master pages and the application.master file are generally the same but do have some very slight differences.  You cannot simply copy your regular master page content into the application.master file and expect everything in SharePoint to work perfectly, they are not 100% compatible.  However, you can take your regular master page and tweak it (with little effort) to use as your application.master file.  Below is an outline of the “tweaks” that need to be made

Tweak 1.  Application.master files should not contain the delegate control for the SmallSearchInputBox.  You can simply remove the following reference from your master page:

                        <SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox"/>

Thus far I’ve only found that this one “tweak” or change needs to be made to a master page in order to use it as your application.master page.  If you find that there are other required tweaks, please pass those along to me so that I can update my post.

SharePoint 2007 – Page Redirection / Bad Links Solution

Recently I was faced with this customer situation: “Replace my existing web site with a SharePoint 2007 site AND handle all the existing links to my site gracefully”.   Basically the customer asked me to build them a new public facing web site and asked that their existing page links (those in search engines, other web sites and links saved by their customers) continue to work and don’t become “dead” links.

I’ve heard this request when building Intranet sites and Extranet sites, but it’s probably most important when SharePoint 2007 replaces an existing Internet site because you have less control and contact with the audience.  With Intranet and Extranet sites you often have the ability to notify site users that the links to their sites and documents may be broken and you may even provide documentation and training on how to deal with the new site taxonomy.  With Internet sites you don’t have the same relationship with your users (customers) so your SharePoint 2007 site often has to handle the old links gracefully. 

With public facing sites you often reply upon search engines (Google, Live Search, Yahoo, etc) to find your site and you want to be sure that the stale links in those search engines do not lead to dead ends.  Most search engines today provide webmaster tools that allow you to remove dead links and provide updates site maps.  See my article on site maps for SharePoint.   Below are links to the three most popular search engine webmaster tools:

• Google Webmaster Tools
• Live Search Webmaster Center
• Yahoo Site Explorer

There are two basic approaches for solving the page redirection and bad link issues; 1.  Translate the http requests before they reach the site, or 2. Make the site “smart” so that it can redirect the http requests to the appropriate destination.

Things to consider before you begin building a solution:

1.  Identify all potential inbound links to your site and document those (I recommend creating a SharePoint list or spreadsheet).  Be sure to visit all major search engines to see what pages are indexed by those search engines, those links should be included in your list.

2.  Determine if your inbound links use query string parameters; for example: a link like http://www.kroger.com/privacypolicy.htm does not use query string parameters where a link like http://www.kroger.com/page.asp?tabid=143 does use query string parameters.  This will depend heavily on the technology used to implement the site you are replacing and may impact your choice on solutions.

3.  Identify the tools at your disposal; For example; is there a hardware-based firewall, a software-based firewall, load balancing software, load balancing hardware.  It is often easier to leverage one of these tools for page redirection rather than going down the custom programming path.

Solutions for handling page redirection include the following:

1.  Firewall or Load Balancing – Configure your firewall to “listen” for the set of inbound links and have your firewall redirect the request to the desired destination page.  If you are using Microsoft ISA Server you can enable Link Translation to handle the transition to the new addresses.  Other firewalls and load balancing solutions provide similar functionality to ISA, so be sure to check with your vendor.

2.  Custom Redirection Page – Implement a custom ASP.NET page inside SharePoint to handle all 404 errors.  

3.  Use the Codeplex Smart 404 Feature created by Josh Carlisle.  This is the solution I’ve used the most and I’ve found it very effective. 

In my next post I will guide you through the use of the Smart 404 Feature and provide you some sample code for extending the functionality of that feature.