SharePoint Theme Settings page and Enhanced Theming

If you create a site using the Blank template and go to Settings > Site Theme you get a simple page that lets you set your site theme.

If you create a site using the Team Site template and go to Settings > Site Theme, you get a more advanced page.

Both these experiences are supported by the one page (/_layouts/themeweb.aspx). So what gives? Continue reading “SharePoint Theme Settings page and Enhanced Theming”

SharePoint Theme Settings page and Enhanced Theming

Automatically add themes to the SPThemes.xml file

I’m not sure I’ll use themes again over the AlternateCssUrl again in a hurry, but I did decide to take a look at the 10 example themes Microsoft Released in March. I’ll blog about how they look – sometime! (The short answer – some good, some bad, some awful!)

Anyway, I was interested that the themes could all be activated as features. This rather kept with my feeling on how branding should be deployed.

However, some of the themes (though not all) were suddenly available in the ‘Site Themes’ page of my SharePoint system. I knew from experience that this isn’t something that ‘just happens’ – previously, I’ve done it by hand.

EDIT: See the comments – they describe an possible pit fall, but both have articles about how to do the same thing… Continue reading “Automatically add themes to the SPThemes.xml file”

Automatically add themes to the SPThemes.xml file

Deploy Publishing Pages and Content Types as a feature

Aka “CAML is the bastard spawn of Satan”.

So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.

I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.

Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this. Continue reading “Deploy Publishing Pages and Content Types as a feature”

Deploy Publishing Pages and Content Types as a feature

Feature Stapling for Branding

As I’ve mentioned before, I reckon that from now on I’ll do all SharePoint branding through features alone – not using themes or the ‘choose master page’ page. Which is fine, and useful too – one of the questions that has been raised recently is how to automatically apply the branding when a new site is provided. Well, feature stapling is the way to do that.

For those who don’t know, feature stapling is creating a feature which associates another feature with a Site Definition. When a site is provided by that site template the associated feature is activated. So, for example, we might have a BrandingFeature feature, which does all of our setting alternate CSS, setting master pages, etc., and then use a BrandingStapler feature to associate that with some (or all) of our site definitions.

I won’t bother repeating the ‘how to’ of it, as there are plenty of good posts about it.

Feature Stapling for Branding

Where to put CSS when branding?

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.

Where to put CSS when branding?

Feature Receiver to apply master pages to normal or meeting sites

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”

Feature Receiver to apply master pages to normal or meeting sites

How to find out what type of site a site is…

I’ve built a feature to active branding on a site including master page, navigation and themes, which I’ve been talking about a bit over the last few weeks. One issue, though is that meeting workspaces have a different master page to ‘normal’ master pages, so I need to set them to use a different ‘custom’ master page when the feature is activated. This means that my feature receiver has to ‘know’ if the site it’s being activated on is a Meeting Workspace, or some other site.

What defines the ‘type’ of a site is the template that was used in it’s creation. Continue reading “How to find out what type of site a site is…”

How to find out what type of site a site is…

Style the DatePicker using an Alternate CSS

A while back I posted about the how daft that the datepicker control isn’t styled by themes, and is in the _layouts directory, so you shouldn’t edit them.

Well, a while later Michelle posted with a good idea of how to brand them – use an alternate CSS URL. I must confess, this tip passed me by until my recent branding efforts, and I discovered her tip.

So why does this work? Well, if we crack open the file iframe.aspx (which I still think is a bloody stupid name. I mean, the defining feature is the DatePicker control, not the bloody iframe it uses) we can see the code:

There we go – code to insert the alternate CSS url (but not themes – obviously).

So, I gave this a go:

Tada! Styled date picker, nice one Michelle. However, she notes that it has to be applied to a publishing site, or to a publishing site and all sites below it. Site collections based around a team site would be tricky. Normally, this page is used to set the alternate CSS…

[image of site]

… and, well, Team sites don’t give you that page.

However, we can achieve this in code! All the admin page does is change the SPWeb.AlternateCssUrl property for a site or set of sites. We could have a feature receiver (a bit of code that is run when a feature is activated or deactivated) to do this:

public override void FeatureActivated( SPFeatureReceiverProperties properties ) {

SPWeb site = properties.Feature.Parent as SPWeb;

site.AlternateCssUrl = "[Your URL here]";



More evidence that brands are best applied by feature receivers. Maybe I should make an example of this…

Style the DatePicker using an Alternate CSS

Programmatically apply a Default Theme in SharePoint

As I’ve mentioned before, I’ve written a brand that is a combination of Theme and Master Page, and is designed to be activated by a feature receiver. When the feature is deactivated, it should restore the previous Master Page and Theme – but it wasn’t doing this for the default theme. Weird.

Well, here’s another good tip from Madalina you have to apply a theme of none, not Default.


That’s the second tip of hers I’ve found on Google and used in the last 2 weeks. Maybe I should start watching that blog. Anyway, I guess that ‘none’ makes sense when you look in 12/TEMPLATES/LAYOUTS/1033/SPTHEMES.xml – the default theme has a TemplateID of ‘none’.

‘Course my next problem for my feature receiver is that Meeting Workspaces use master pages (MWSDefault.master) that are significantly different to other pages – thanks guys, that’s helpful…

Programmatically apply a Default Theme in SharePoint