Jun 16, 2010

Automatize MasterPages in SiteDefinitions

When building a branded SharePoint2010 solution, the customization of Master Pages is the issue. And as I've stated in a former blog post, one Master Page is seldom enough. In the least, the Search Center needs one of it's own. And maybe we need a customized Team Site? Or two? And one for BI reports? Etc.

Basically, when creating a branding solution - or any solution - you will want to use a feature. And preferably package it all into a wsp package, neat to deploy. It used to be complicated with a lot of handi-work when creating these in VisualStudio, but not anymore. VisualStudio2010 contains SharePoint 2010 project templates natively, adds many of the needed xml files, fills in features by demand, creates the wsp package... and makes SharePoint development extremely flexible by deploying the solution to your development environment with one click, activating your features on the go!

Thus, though, it is easy for a developer to forget a couple essential things for when the time comes to deploy the solution to the test environment of the customer.

1) It's rather convenient to set your features to activate whenever a site of the type is created. This is done by adding a sigle (or two, with the commentation of the code) line in the onet.xml file of the site definition:

inside the web or site (depending on the scope of your feature) features collection of your site definition configuration(s).

2) Create a feature receiver. The automatic activation of a feature is next to nothing it nothing happens. A feature receiver defines what happens when the feature is activated, eg. the MasterPages to use and where. In the simplest scenario, it defines one master page for the whole web. But it's not a big deal to make it acknowledge the different site definitions you've created. This way you can package them all in one feature instead of a minion.

In my example here, there is custom team site and a custom search center site defined with their own master pages plus the overall portal master page used everywhere else (for accuracy, I used the custom WebTemplateId's of my SiteDefinitions instead of WebTemplate names - possible also, but didn't work for me)


The code exerpt above is only the first half, you need to define likewise what to do when the feature gets deactivated.

[Edit. Jan 18th, 2012
For MasterPage automatization withour custom SiteTemplates, see Setting MasterPages to Sites Automatically.]

No comments: