However, they can be restored… Continue reading “Add Breadcrumbs back into SharePoint 2013”
The product of many evenings in hotels recently, I’m proud to present, my Application Master Page Changer.
Application master pages are tricky – out of the box in SharePoint 2007, there is no way of changing the master page used for ‘administrative’ pages. Unfortunately, those administrative pages include things like the recycle bin, file upload, and the ‘View all site content’ pages – things that users will likely see.
Well, folks have found a solution to this – using an HTTPModule to intercept pages using the normal application.master and redirecting it to use your custom one. This works pretty well, but I was always a bit uncomfortable – what if you only want this to happen for particular site collections, or specific sites within a Web Application? I’d tried knocking up an HTTPModule to do this, but matching against URLs – bit it was awkward to configure, complex, and adding new sites/site collections could be a bit annoying – basically, a nightmare to configure.
What we really need, I thought, is some way of just turning on/off the master pages being used with Features. And that’s what I’ve built. Check it out here…
Well, I’ve just built a lovely little HTTP Module that lets us redirect the application pages for a site or site collection to a new master page. I’m quite pleased, to be honest. Anyway, I noticed that the error pages in the site I was testing on were not using my new master page, so I started to examine this. I found that the error page (_layouts/error.aspx) is busy using simple.master. WTF?
It makes sense, I guess. You do need a master page which doesn’t run in an authenticated context, and a brief check shows that this is the master pages for the out-of-box Forms authentication page.
I decided to check out if there were other master pages in Layouts – and there were. My list of master pages is now:
- Default.master – used in normal sites. Often replaced for publishing sites.
- MwsDefault.master – use in Meeting Workspaces. Awkward to replace, but can be done through code or SharePoint designer.
- Application.master – used in ‘administration’ pages, and sometimes pages such as ‘View all site contents’, Recycle bin, and uploading a file.
- Simple.master – used in pages that need to run in an unauthenticated context – such as error pages, or forms authentication pages.
- sspadmin.master – seems to be used editing audiences, in excel services configuration, in profile administration, and handful of other places.
- layouts.master – no idea what this is for. Can’t find where it is used!
- dialog.master – used in the little pop-up dialogs, such as when you’re adding or editing a Hyperlink.
- pickerdialog.master – used in pop-up dialogs such as the web part gallery, or selecting users.
The master pages in italics are comparatively easy to replace; the rest are much more difficult. And try as I might, I couldn’t change the master page for Errors in my HTTP Module. I guess what I’ll do is write another one to redirect errors to my own custom-branded error page.
I’ve recently come to the conclusion that I’m unlikely to use Themes in SharePoint again in a hurry. Why?
- Themes allow you to provide a bunch of CSS styles. So does the AlternateCssURL.
- Themes have to be applied site-by-site (unless you do some programming, or extend STSADM). Alternate CSS or Master Pages can be changed for a site and subsites, for a Publishing site anyway (although with some limitations).
- Alternate CSS can be provisioned from a single URL – so benefiting from browser caching just like images.
- The Alternate CSS can style the DatePicker. Themes can’t.
- The Alternate CSS can style Application Pages, just like Themes (but unlike Master Pages).
- No problems with ‘Style Merging’ when the Theme is provisioned.
- Style can be updated in one location.
- Themes can be changed through the UI for any site. Only Publishing sites have a user interface for changing the Alternate CSS.
Yes, many of the same distinctions between Master Pages and Themes still exist, and the same sort of analysis and choice of approach should be done. However, it means that we can kind of ignore Master Pages, and just focus on Alternate CSS vs Themes – and it seems to me that apart from the last point above, the Alternate CSS approach seems to equal or better than Themes.
Regarding the last point, well, to apply my theme I’d set the Alternate CSS in a Feature Receiver. This is okay, though, as I’d probably be writing one anyway to apply the correct master page to different types of site.
So, the answer I’ve come to now – I’d use the _layouts directory – create a sub-directory for your brand, and put your CSS and images in there.
As noted previously, Meeting Workspaces use a different master page to the ‘normal’ master pages in SharePoint. This is a little annoying – if I need to apply a new master page, how would I do this?
Well, you can activate a new master page in a Feature Receiver. And we can detect the type of site we’re dealing with. Why not combine the two techniques Continue reading “Feature Receiver to apply master pages to normal or meeting sites”
So, 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 MasterUrl and CustomMasterUrl properties, how does a page ‘know’ which one to use? Why do publishing pages use the value in CustomMasterUrl, and other pages use MasterUrl?
Well, to find the answer to that, you’ve got to look in the code of the .aspx content page. Here’s the top of one in SharePoint Designer:
Yup, there is a MasterPageFile as per standard ASP.NET. However, the value of this isn’t normal – it’s not the URL itself, but rather a token that gets replaced at runtime.
- ~masterurl/default.master is resolved to the value of the MasterUrl property (i.e. the ‘System Master Page’ on a publishing site).
- ~masterurl/custom.master is resolved to the value of the CustomMasterUrl property (i.e. the ‘Site Master Page’ on a publishing site).
If you look in, say, the default.aspx page on a team site, you’ll see that it uses ~masterurl/default.master.
If you look in, say, the default.aspx page on a meeting workspace, youll see that it uses ~masterurl/custom.master.
If you look in publishing pages, though, you have to look at the page layouts (which are the actual .aspx pages being used). These don’t have a have a MasterPageFile defined – what gives? Well, they inherit from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class, which sets the master page file internally during OnPreInit! You can see in Reflector that it’s using CustomMasterUrl though.
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… Continue reading “Setting a Site Master on a Publishing site breaks Meeting Workspaces”
Irritatingly, in SharePoint Meeting Workspaces have a different master page to most sites (mwsdefault.master and default.master respectively). The differences are actually quite minor – the Meeting has a ‘Custom Tool Pane’ control, so you can add new pages, and a tab bar:
In the code, the pages are very similar, which makes it all the more irritating that they’re not simply the same. As far as I can see, there is no need for this – at least, nothing that can’t be dealt with by content placeholders – which is what they’re using to get rid of the left navigation. Anyway, I digress – the real question is can we customise them, and provide consistent branding on them? Continue reading “Custom Master Pages for Meeting Workspaces”
A customer wants to put a web part zone below the quick nav in their SharePoint site – not an unusual request. Naturally, I cracked open SharePoint Designer, and tried adding a web part zone – and this is what I got:
I tried to understand why this would be the case, but quite simple, couldn’t. Naturally, I then referred to the documentation (!) on MSDN. It had mentioned this at the bottom of the page.
You cannot add Web Parts in zones to a master page. You can add static Web Parts (parts outside of a zone) to a master page, but you cannot add dynamic Web Parts to master pages.
Okay, that seems clear enough – I get why you could add static web parts to a master page, but not dynamic – but what about the web part zones themselves?
You can add zones to master pages and later add Web Parts to the zone in the browser, but the Web Parts are associated with the content page.
Yup, that seems fair enough. I get that in theory. So why in practice does SharePoint Designer say I can’t?
I began looking around to see if others had tried this – and found interesting contradictions. Mirjam says you can’t – but does point out that you can override the standard quick nav in your page layout, and put a web part zone into that. Microsoft SharePoint Step by Step seems to say the same thing. Yet ASP.NET would support this just fine, and as noted the MSDN docs say it should work.
Okay, one thing left to do – actually try it. SharePoint Designer won’t let me add the web part zone by ‘drag and drop’, but I can code one by hand:
And it renders in SharePoint Designer:
But when you try and use the page:
Well, I ain’t going to argue with a parser error – it looks like you really can’t do this, despite the MSDN docs.
I’ve been doing some branding for the last week or so, and today was the turn of the left nav menu. I’ve gotta admit, I don’t like doing this – it’s complex, fiddly, and leaves me with what I call “SharePoint Branding Tourettes”.
While going through the code for the left side of the page, I came across the PlaceHolderLeftActions placeholder. By default, it’s empty.
It was a bit of a puzzle to me though – it sits just underneath the normal left navigation area of the page, and I couldn’t think of anything that puts content down there. Just to check though, I took a look in IE Explorer:
I’ve highlighted where the content goes, and you can see from the IE dev bar, there is a hidden link there (to the List Settings page, if you’re interested).
Hmm. So some stuff uses it. I tried different lists in case they all used hidden content – and fairly rapidly came across another – Wiki pages:
I guess the real annoyance here is that it is so hard to see what pages in SharePoint use what placeholders. It’s not like you can just search over the file system, even. I guess it’s a matter for experience.
Anybody else know what the PlaceHolderLeftActions is used for? I might try and build up a library.