Previously I found (in ‘David’s Blog’) a way of using an HTTP Module in SharePoint to change the master page used by ‘application’ pages. I fiddled with it a bit and made it work properly.
Unfortunately, I’ve lost my code (HD crash) and David’s blog is defunct (I think it died when the SharePoint Blogs site died).
So, some links to similar relevant pages:
Themes in SharePoint are tough. I think this quote describes it nicely:
If you have attempted to override the styles on an out of the box SharePoint site, you know that it isn’t a very easy thing to do. The core.css file that contains the basic rules has 979 different style rules.
The core.css file uses a palette of 132 colors and 143 images.
The default page of a newly provisioned team site uses only 61 of those rules.
So, unless you have branded a lot of SharePoint sites and are intimately familiar with core.css and the default master pages and page layouts, just figuring out where to start modifying can be a daunting task.
So Doug has built SharePoint Skinner to make that easier. I’ve not tried it (yet) but I like his thinking…
So, Joel Oleson has blogged a bit about master pages and themes in MOSS. This is an area I think that the SharePoint team have the right idea, but execution is a little short.
My problems are that we have master pages – which is great. And we’ve got seperate master pages for standard pages, and administration pages. Okay, I’m happy with that. However, there is a mechanism for changing the master page for normal pages – but nothing for administration pages. ‘Cos nobody will ever look at them, right?
Then there is the question of master pages and themes. I really like some of the themes that come OOB, much more so than the default ‘blue’ (I like ‘Simple’). But they can only be applied on a site by site basis; there is no inheritance mechanism. And if you use a master page, it’ll probably override the theme anyway. So why have themes? Why not just use master pages?
One of the pains about master pages in SharePoint is that when you set one for a site, it doesn’t apply to the admin pages. This can lead to a, um, interesting difference in appearance.
I started looking into overcoming this. Obviously, there is a fairly straight-forward approach – modify the application.master. Ouch. Then, any changes to design in one file have to be replicated elsewhere, with one file in the Master Page Gallery, and one on the file system.
Alternatively, I found a neat solution at David’s blog. This uses an HTTP Module to reset the master page for any pages looking for application.master.
But after following his instructions, my admin pages wouldn’t work. I just got the error page ‘Unknown Error’.
Digging into the logs, I found what was going on – there were 2 content placeholders that the application.master uses which weren’t on my ‘normal’ master page. Make sure you add place holders for:
<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr2" runat="server"/>
The full list of placeholders used in both files is:
Dump of links to do with MOSS Branding from Angus Logan. Lots of stuff from Shane Perran in there – yup, I’ve been reading a lot of his posts now that I’m trying to rebrand a site.
Bit of a shocker – no inheritance of themes through a site hierarchy in WSS3. There is of Master Pages, but not of themes.
Given that you can do all of what you do with Master Pages it does make me wonder – what are Themes for?
Updated: Heather Solomon has looked at it, and her suggestion is to just put your styles in the Master page.
Updated again: Or just use the Alternate CSS URL for your site.
Andy Burns' Blog 