Custom application.master – working around Microsoft bugs

I created a very customized application.master page and I followed all the best practices I could find. I had all the right content place holders and I did not implement the search control on it. These were the two basic recommendations I could find from other people in the SharePoint field.

So, the new application.master was created and everything seemed to be working fine. Then one day we went to check in a file and noticed that we couldn’t check in. The check in page had a “title” and a “description” but everything under it was blank. I did a view source on the page and the html for the check in page was actually there, it just wasn’t showing.

At this point I was baffled. So, I decided to go look at the checkin.aspx page that SharePoint actually uses. While on this page I concentrated on the “Description” section because that was the last section that actually showed up. When I looked at the jumbled mess that Microsoft calls html it seemed to look fine (except for their inconsistent use of capitalization and tabbing – that drives me crazy ).

So, I formatted the html a little better and I noticed something very interesting:

Now, take a close look. I always thought you had to close your td’s before closing your trs’s. This is what Microsoft gets for writing this jumbled html.

The only thing I can’t figure out is how they managed to get their application.master pages to work. There are two possiblities in my mind (but there might be others, I am just guessing here):
1. There is bad html in the regular application.master page which somehow closes the tags off.
2. Quirk mode – SharePoint runs in Quirk mode. Quirk mode is basically a way to keep non-standard html pages to render correctly. It tries to “fix” certain errors automatically. However, it has issues because every browser fixes “quirks” differently. Thus, it is never a good thing to rely on this to fix issues.

So, this is no good if you write clean html in your custom application.master page, because it is actually the Microsoft implementing page that has the error in it.

My solution to fixing this was to place the PlaceHolderPageDescription in a hidden panel on my application.master. Now, this means I will never get these descriptions in my application pages, but that is something I am willing to live with.

Customizing Application.master

I often show people how to create custom site definitions with custom masterpages for their SharePoint sites. And, every time the dreaded application.master issue comes up.
SharePoint is a mix of database and server files (12 hive). The mixture of these shows the site. Basically, the database contains reference to piece together information from the 12 hive files to build a website.
However, there are some “static” pages in SharePoint for “helper” pages. These are called application pages or layout pages(because they show up under _layouts). You can always tell one of these pages because _layouts will be in your url.
Now, application pages cannot use the masterpage we create with our features or site definitions because they know nothing about the database. They have to use their own masterpage called application.master.
The application.master lives in the layouts folder with the rest of these files. Now, the issue is, there is one application.master for the entire server. So, if you have multiple web applications, customized different ways, they have to use the same application.master for the application (layout) pages.
Now, most of the application (layout) pages are for administrative functionality, however, there are a few the end users will see (for example: the search page).

So, how do we modify this application.master page.
Well, there are 2 approaches Microsoft recommends per their help article – http://support.microsoft.com/kb/944105:
1. Modify the application.master page – really Microsoft, you really want us to do this. You are the ones who say best practices are not to modify files from the 12 hive. Now, when you implement something that is not scalable you change your mind. I hate it when Microsoft does this. But, I still use this approach sometimes because it is so easy . So, what is the problem with this approach? First off, this modifies the application.master for your whole server – thus you can’t have mulitple web applications with different application master pages. Second, you are modifying 12 hive files and a SharePoint service pack could overwrite your changes (but this is unlikely).
2. Create a custom layouts folder – once again, really Microsoft. This seems like a horrible implementation to me. Another hack they are recommending to us. It gets you around the multiple web applications with different customization issues. However, it creates a maintenance nightmare.

Now, I do implement number 1 above if I don’t have much time and it won’t hurt my specific requirements. However, I don’t like either of the Microsoft recommendations and I think they should be ashamed this is what they recommend.

My suggestion is to use HTTPModules. I could explain the steps in this blog, but I would just be reiterating something I learned about in another blog. So, I will just give the link to the blog I learned how to do this in to give that author the credit: http://www.sharepointblogs.com/dwise/archive/2007/01/08/one-master-to-rule-them-all-two-actually.aspx

Maybe next version of SharePoint will make application.master configurations more scalable. But for now, creating httpmodules is our best option (at least it is the best option I have found so far).