Tilting at Knowledge Base Windmills
I’m probably going to take some flak for this but sometimes you’ve just gotta stand up and shout when you see officially sanctioned advice that appears to have come right out of left field. I’m referring to KB944105 – How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0. This is a subject that has long been an Achille’s Heel for serious branding efforts so when I saw the title I was hoping to finally get some good guidance on how to handle it. Instead, I find myself shaking my head and wondering just what to make of what I’m reading.
For those of you not familiar with the issue, when you deploy a custom master page in MOSS/WSS v3, the master page is not inherited by the globally-accessible pages in the ‘_layouts’ folder, known collectively as ‘Application Pages’. These pages provide UI elements necessary for the performance of tasks common to every site collection – viewing and creating lists, setting permissions, modifying list settings, adding content types, browsing for users, etc. The reason for this is simple – these pages are used by all site collections and thus cannot be tied to any single site definition style and branding.
The problem, of course, is that here in the real world customers want these pages to look like the site they are accessed from and not the default SharePoint chrome. And it’s not a ‘want’ it’s a resounding ‘need’ – a must have that is non-negotiable. An understandable request but one for which we have no effective answer because the master page inheritance model is specifically truncated for application pages. This leaves us with few options – modify each page individually with code to handle multiple master pages or add our own handler mechanism via HTTPModules to do the work for us.
Naturally, neither method is supported by Microsoft. In the first case, we are told never to modify existing files for compatibility, upgrade and supportability purposes. Okay, I get that. In the second case, we are told that custom HTTPModules should not be used although I have never received a clear answer as to why this is so. I can only assume, because people in the know have told me as much, that there is concern over custom code interacting with the existing HTTPModules that MOSS uses (although this is an obvious straw man argument as the same could be said for event handlers, server controls and web parts).
Um, okay, well, that leaves us in a bind then, doesn’t it? Don’t mess with the existing code and don’t circumvent it either. So I’m already confused when along comes KB944105 that tells me the recommended method for solving this problem is – are you ready for it? – modify the existing code! Huh? Did I just step off a ledge into a parallel dimension or what???
First and foremost, the "recommended" solution (make a backup of the existing 12\Template\Layouts directory then customize all the existing pages) is no solution at all. Have you ever counted how many pages are in that directory? Well over a hundred. Touching each one individually would be an exercise in futility. Putting that small issue aside, the even bigger problem is that the recommended solution is only valid for a single site-collection. Have two site collections on the same farm with different branding? Sorry, pal, you’re out of luck. Finally, and this is what really gets me, we have been told all along that this is the WRONG way to modify anything in SharePoint. And most of us support this methodology because we agree in principle with the idea that changing up what comes in the box is just plain B-A-D.
So on to solution number two which, recognizing that solution number one simply won’t scale, suggests that we instead change the default virtual directory mappings in IIS and create multiple layout folder instances. Well, okay, I suppose that solves the one farm/multiple brands issue, but then you end up with numerous copies of the same files to manage (did I mention that there are more than a hundred of them?) AND you violate another principle of SharePoint customization which is to keep your hands off the IIS configuration and manage everything through Central Administration. To make matters worse, the article actually warns that taking this approach may break existing functionality that relies on a hard-coded path to the layouts folder. Ignoring the fact that such hard-coded values ought not to exist in the first place, this means we’re breaking yet another rule against interfering with OOTB functionality.
I don’t know about you but my head is starting to hurt from the implications of this article. First, we’re told not to do something (several somethings, actually). Then we’re given advice that had to be vetted by someone on the product team that says no, go ahead and do the things we told you not to do. And still no mention of the one thing that actually does work in all scenarios without breaking any rules or hosing your server farm – custom HTTPModules.
I swear there must be people in Redmond with stock in Glenfiddich who do these things to me when they notice my whisky consumption has dropped below distellery-sustaining levels. If anyone can shed the light of common-sense on KB944105 to those of us stumbling about in the dark, you can find me on the back porch crying my way through a bottle of Ancient Reserve…
I agree that whatever method you use will be a pain in the …
But can MS word this to be anymore confusing?
“Modifying the files that are installed by SharePoint is not supported.”
and a little later…
“Product support will provide commercially reasonable support for help with modifications.”
So they will help you do the mods, but once you are done they say: “sorry I can’t help you”?
Eric, I’m with you – the KB article is nonsense! Neither of the suggested approaches have the flexibility of a custom HTTP module. The reference to hardcoded bits of the product which may refer to ‘layouts’ isn’t what I wanted to hear either.
I’ll be sure to test thoroughly, but at the moment it’s HTTP modules for me I think. I’d like to see MS do some testing and offer some better guidance on this.
Chris.
I have been wondering why the option in the site settings – under look and feel -> masterpages — where you get to specify which “system page” masterpage to use – doesn’t handle this. It seems to me like that was what that was intended for
Do you think there would be a way to get the _layouts pages to think of themselves as systems pages?
I think I will go for the http handler technique – although I have not tried it yet