Site definitions vs. Web templates

  • Article

I keep getting almost daily emails concerning WebTemplate element support and when it would be proper technical approach for the site provisioning with SharePoint 2010. There’s no doubt that many times there’s requirements to be able to provision sites as easily as possible from content editor perspective, so let’s still elaborate or evaluate different options and common misunderstandings with these options.

Detailed explanation of different available options can be found from my previous blog post (also has step by step guidance on custom WebTemplate usage). Mirjam also has done good work on explaining WebTemplate in her blog post titled as same as this one. Notice that when I’m writing about web templates, I refer to WebTemplate element usage with onet.xml, not what get’s created when you save site as a template from browser (site template wsp package), even though site templates uses WebTemplate element in them.

Here’s quick list of advantages and disadvantages on both approaches. Let’s also add some cloud perspective on the topics, since it seems to get cloudier and cloudier all the time, especially now with the Office365 being released few months back.

Notice that I didn’t include feature stapling or features to the game, since in this post we’ll concentrate on having new options available in the Create Site functionality, rather than just changing how the existing templates will work using feature stapling or manual feature activation. Following chapters will list random pointers for both sides (advantages and disadvantages) which you should be considering when you create your technical plan for customizations.

Site definition

  • There’s no supported way to upgrade or modify already deployed site definition
    • It might work, but it’s not supported
    • There’s options to mitigate this, but there’s wider impact on architecture planning and technical solution
  • Site definitions are always deployed farm wide and cannot be targeted to more granular scope
  • There’s own template in VS2010 for site definition
  • Feature staplers can be targeted to site definitions
  • Variations will only work with site definitions
    • Note. This is not translation or multilingual solution, it’s for structural copy. Following sites as an example are not using variations – www.kone.com in English (US), Chinese and in Russia
  • Not supported by cloud services, like Office365 (Standard or Dedicated)
  • Upgrades to following SharePoint major version (o15) will require additional costs
    • All sites created using custom site definitions are stamped with custom identifier and won’t be upgraded automatically
  • Hierarchies can be easily created using separate xml formats
  • Only supported as farm solution deployable functionality

 

Web Templates

  • Can be easily updatable just by modifying onet.xml and deploying new version of that available
    • Note. Update does not have any impact on existing sites, since there’s no runtime reference to them
  • Can be targeted to Farm or Site collection level – provide more granularity for exposing site options
  • Feature staplers cannot be targeted to web template
    • Note. Since you can modify onet.xml directly and deploy new version of that anytime, there’s no use for feature stapling with WebTemplate element
  • Variations won’t work with WebTemplate element deployed onet.xml files
    • There’s already few custom solutions available, which makes variations also to work with sites created using WebTemplate elements. Logic is not that difficult, but requires customizations
  • Supported by cloud services, like Office365 (Standard or Dedicated)
  • Upgrades to following SharePoint version (o15) won’t require extra work – completely same as somebody would have created site using out of the box site definition and then activated extra custom features from site settings page
    • Actual features have be obviously upgraded correctly
  • Supports publishing features, like site definitions – so can be also used for Internet facing sites
    • Good example of Internet facing site created using WebTemplate elements in www.upm.com which also has numerous different languages (France, German, Finnish)
  • Hierarchies can be easily created using feature receivers and code
  • Creating custom web template is easy as creating custom site definition
    • Note. Don’t start by importing existing site template (wsp package) as suggested in the MSDN. It’s much more easier to convert any existing site definition to web template simply by copying onet.xml and creating other required elements manually. Check my previous blog post for details.
  • There’s no designers in VS2010 for WebTemplate
    • This should be fixed by VS.next to promote multiple platform options – as in not to force to be only in on-prem like with site definitions – “We are all in…”
  • Can be deployed from farm solution or from sandbox solution
    • Notice that has to be obviously in Site Collection scoped feature, if deployed as Sandbox solution

 

I upgraded from 2007 and have site definitions – now what?

In 2007 we didn’t have any other options than using site definitions with certain business requirements, so it’s understandable that there’s numerous sites which are build technically using custom site definitions. These deployments won’t be cloud compliant unless dependency to these site definitions is removed. This means that these kind of deployments cannot be migrated to Office365 (Standard or Dedicated) without complete refactoring of code and content as pre-requisite.

These kind of refactoring projects are not simple and could be surprisingly expensive. If you are planning to migrate away from custom site definitions, you might want to consider to take a approach where you rebuild customizations using WebTemplate element and then migrate just the content from the existing sites to newly developed customizations. You might want to consider this as one of your options when you define required changes for the customizations anyway due the version upgrade from 2007 to 2010.

Summary

As a summary, you should be using WebTemplate element whenever possible to provide site provisioning options to your deployment.

As a Microsoft consultant, I also personally would prefer people to use more cost efficient options in long term when they design their customizations to avoid any hidden cost impact or unnecessary cleaning in later stages of the deployment life cycle. By using WebTemplate element over site definition, we still provide complete flexibility for the customers to host their SharePoint wherever they want (cloud or on-prem) and don’t cause any “stupid” technical limitations for their possible future cloud transition to any cloud platform (like Office365). Even though your deployment would have been currently planned to be an on-premises deployment, you shouldn’t lock it’s future by using site definitions and cause also additional costs as part of the upgrade to following SharePoint major version (o15).

Hopefully you were not forced to do any SP2003 to SP2007 upgrades where custom site definitions where used, but that’s exactly the route where using site definitions also in future will drive deployments. These migration issues should be major consideration point for any SharePoint deployment from overall costs perspective. By selecting WebTemplate approach, your deployment will be as easily updated to following SharePoint major version as it would be using simple stapled features. This has major cost impact on the overall lifecycle costs of the deployment.

Notice also that since WebTemplate element usage is also based on same onet.xml structures like site definitions, you can easily learn how to use them, so that your customization architecture is following up guidance's to avoid any unintentional costs for the deployment during maintenance phase of the sites.

So – forget site definitions, start using WebTemplate elements in your deployments, this will be beneficial for your customers, you and any SharePoint deployment in short and long term.

If you disagree any of the pointers listed above, don’t hesitate to contact or write comments on this blog post. We would like to also understand what are the concerns and possible issues you might have run into. Thanks for the comments and pointers advance.