SharePoint Branding Issues: Application Pages

Application pages are those special pages within SharePoint that share functionality accross sites. Some examples include the site settings, the list settings, each setting page within those settings, the All Site Content pages, the personal settings pages, etc. A way to directly recognize one of these pages is to look at the URL of the accessed page. If the url contains this segment “/_layouts/”, you are dealing with an application page. Why? Well, the /_layouts/ directory is a virtual directory created by IIS and is available to every created SharePoint site. You can access every page within the layouts directory by simply adding the path to your site url. For example: http://www.host.com/subsite/_layouts/settings.aspx. But where does this path redirect? The _layouts virtual directory is mapped to a fixed directory within the SharePoint hive, more specifically: C:\Program Files\Common Files\Microsoft shared\web server extensions\12\TEMPLATE\LAYOUTS\. So, every page within this directory is accessible through the special \_layouts\ directory.

Another way to recognize these pages is that, if you use a master page other than the default one, the application pages still seem to use the default master page. I write “seem”, because although the appearance seem to be the same, it is a different master page. This master page is also located within the layouts directory and is called application.master.

If you want a complete make-over of your SharePoint site, chances are you’ll want to change the appearance of those pages. One way to do this, is to edit the application.master master page. This can be a valid solution if your whole farm uses the same master page, as all application pages of the sites on your server use this system master page. So, if you change the master page, the changes will be visible on all instances. Most of the time, however, you have different sites on your server with different branding needs. So this approach is usually out of the question.

My solution consists of altering the application pages themselves. Although this is not a recommended practice, as Microsoft is not supporting this (Service packs could overwrite the changes), sometimes it’s the only option left. Let me show you what to add:

<script runat="server">
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
MasterPageFile = SPContext.Current.Web.CustomMasterUrl;
}
</script>

Basicly we’re assigning, at run time, a new master page to the application page. Application pages can use the SPContext object to find out the context in which they are called. From this object we extract the current site (a SPWeb object) and assign the CustomMasterUrl property as the application page’s master page. This will do the trick just fine.

An important note to this solution, regards the master pages themselves. Master pages for application pages need to support two extra content place holders, PlaceHolderPageDescriptionRowAttr and PlaceHolderPageDescriptionRowAttr2. As these place holders don’t seem to do much, you can just add those two tags within a hidden ASP.NET panel to your master page.

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

If you are using this technique, be sure to add these tags to the default.master master page in the SharePoint hive and this for compatibility reasons with the other sites. Of course, do not forget to add them to your custom master page too, as this is usually the reason, in the first place, to apply this solution.

A nice extension would consist of making the Application Pages Master Page of a site selectable through the UI (in MOSS) for selecting a master page. You could then use the SPWeb property bag to save the master page url.

Untill next time, happy sharepointing.. :-)

5 Responses to “SharePoint Branding Issues: Application Pages”

  1. Sven Gillis Says:

    Dear Tom,

    Thx for sharing your knowledge! Very usefull information…

  2. Tom Says:

    This workaround sounds good, but is there a list of which application pages to change in the layouts directory. There are 400 .aspx files in the directory, do all need to be updated?

  3. Tombo Says:

    Well, a colleague of mine once made a preliminary list of all the application pages to be changed. This list enumerated, if I’m not mistaking the “user” application pages, these are the layouts pages only seen by the average user. (View All Site Content, Profile, etc..) I try to post this list if I find back.

  4. Jeroen Says:

    Instead of making your own custom application pages you can make a httpModule that changes the masterpages of the application pages itself.
    I blogged about it at http://jebass.blogspot.com/2008/11/using-centrally-managable-custom.html

  5. Tombo Says:

    Definitely worth the look. :-)

    Thanks for the comment, Jeroen!

Leave a Reply