So, yesterday I was wondering about custom master pages for Meeting Workspaces. I found that Meeting Workspaces use their own master page (mwsdefault.master), which is referred to in the CustomMasterUrl property of the SPWeb object. As I noted, that sounds a lot like SharePoint publishing sites (i.e. sites with the Publishing Features enabled, like a Publishing Portal or a Collaboration Site).
This rang a bell with one of my colleagues, so he dug out some details. The publishing features let you select a Site Master Page and a System Master Page…
- The Site Master Page is applied to all the publishing pages in the Pages Library of a publishing site. The value for this is stored in the CustomMasterUrl.
- The System Master Page is applied to all the non-publishing pages, such as listviews, standard pages, etc.. The value for this is stored in the MasterUrl
So, the question is, if I reset the Site Master Page for a site, and tell it to change this value for subsites, what happens to Meeting Workspaces? This isn’t an entirely unlikely scenario – you might have a Collaboration site with meeting workspaces within it. I decided to try this.
First, I created a meeting site:
All looks normal – tabs are there, no left navigation, and so on. I went to the parent site, and applied default.master to it and all subsites. My meeting workspace then looked like:
Yup, that’s broken. No tabs, the title area is mucked up, and the left nav has re-appeared, sort of (though it seems to be trying to show the navigation for a repeating meeting).
All of which makes the ‘Reset all subsites’ checkbox a very dangerous thing…
2 thoughts on “Setting a Site Master on a Publishing site breaks Meeting Workspaces”
[…] yesterday’s discussion of the problems with master pages for Publishing and Meeting sites raised a bit of a question with my colleagues. If a site (SPWeb object in the code) has both […]
[…] Hmm. All of this ‘two master page properties’ thing looks a lot like publishing pages. […]