Site Definition and Web Templates in SharePoint

Site Definition and Web Templates in SharePoint

What is Site Definition?

Site Definition consists of XML and ASPX pages stored in the 14 Hive folder. You can locate them in the following folder.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates
Inside the Folder

You can see n number of folders inside SiteTemplates.

Some of the folders which we interact with are:

MPS – Meeting Workspace
Blog – Blog Site

ONET.XML
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\XML\ONET.XML

Creating full blown custom site definitions
Creating custom empty or blank site definitions and provisioning those with (stapled) features and code
Creating site templates
Using custom code
The WebTemplate feature element can also be used to create your own web templates, without saving a site as a template. Just like site definitions, site templates in SharePoint 2010 require an onet.xml file. However, instead of the webtemp.xml file you will use a feature with the WebTemplate element. In the WebTemplate element you will define a BaseTemplateName, a BaseTemplateID and a BaseConfigurationID. In the example below the BaseTemplateName is STS, the BaseTemplateID is 1 and the BaseConfigurationID is 0. Die-hard SharePointeers will recognize the template name and configuration id and know that the basis for the site template we’re creating is the Team Site. The name and title of this site template will be My Fancy Web Template, so this is what will be displayed as the title of the template when you’re creating a new site. The category where you can find the site template in is Fancy Sites. A lot of the other properties can be left out if you’re creating your own site template, I just wanted to list them all in here for your reference.

Creating full blown site definitions and writing a lot of XML for the onet.xml file is not the best option. One of the reasons for this is of course that writing a lot XML is no fun, difficult to debug and very error prone. Another, perhaps even better reason, is that site definitions like this will almost certainly give you a headache when you want to upgrade to the next SharePoint version. Microsoft has been warning people for a while that eventually they will stop supporting site definitions. And it definitely looks like with the WebTemplate feature, they made the first step in that direction.

Using minimal site definitions with features and feature receivers is still an option that can be used. A reason for choosing this approach over the site templates approach could be if you need to use a lot of stapled features.

With the new WebTemplate feature in SharePoint 2010, the use of site templates will dramatically increase. If you are not bothered too much by the limitations of the site template this is a better bet than using site definitions. Mainly because it will make a future upgrade easier. The fact that you can deploy a site template as a sandboxed solution and thus only make a template available within a certain site collection can also be a benefit.

The custom code solution is also a valid approach. I would personally mainly use this when sites are created using automated processes. Of course approach two and three can also use custom code in feature receivers to add functionality to a site. A good reason to use this would be if you need to create list instances and add content types to them. I feel it is way easier to do this in code than to write that out using XML.