One exciting change for developers with the release of SharePoint 2010 is the ability to create site templates that can be packaged and deployed as a solution, but activated as a feature. These features can be packaged and deployed in both farm-trust and sandbox solutions and offer a new defacto standard for new SharePoint template solutions.
In this article, we are going to walk-through how to create a simple web template feature using Visual Studio 2010 to customize the out-of-box blank template to auto-activate enterprise features.
SharePoint 2007 offered a number of alternatives for creating site templates that could be used when creating new sites:
- Site Definitions are deployed to the SharePoint file system, and described in XML schema in a file named ONET.XML. Most of the out-of-box site templates in both SharePoint 2007 and SharePoint 2010 are site definitions.
- Provisioning Providers are code-based solutions that mimicked site definitions, but allowed the site to be created by applying a site definition, and then customizing the site in code.
- Site Templates allow sites to be visually customized using the SharePoint UI and/or SharePoint Designer, and then saved to a template file. In SharePoint 2007, site templates were stored in a .STP file (actually just a normal .CAB file). Site Templates have some limitations however, and do not preserved certain settings most notably permissions.
SharePoint 2010 offers some changes and additions to the SharePoint 2007 approach. Site definitions and publishing providers remain largely the same, but site templates created from the SharePoint UI or SharePoint Designer are now saved to a .WSP file, the same solution deployment packaging file format used for deploying custom SharePoint solutions. Site Templates saved to a .WSP solution file can be imported into Visual Studio for additional customization.
Introducing the WebTemplate Feature Element
The WebTemplate element, introduced in SharePoint 2010, allows site templates to be defined and deployed as a Feature as part of a solution package.
A WebTemplate element feature can be used to deploy site templates in either a Farm or Sandbox solution – without modification. If deployed as a Farm feature and solution, site templates will appear in the site collection provisioning page in Central Administration and can be used to provision new site collections, or within a Site Collection to create sub-sites. If deployed as a Site feature and Sandbox solution, site templates will appear within the site collection to support creating a root site or sub-sites.
Creating a new WebTemplate Feature in Visual Studio 2010
In addition to supporting the ability to save and import Site Templates created from the SharePoint UI into Visual Studio for customization, it can also be used to create new site templates from scratch. In the following sample I will walk through how to create a new WebTemplate solution based on a customized version of the out-of-box Blank Site.
- Create a new Empty SharePoint Project in Visual Studio 2010.
- Add a new Empty Element to the project. I like to create folders for each type of element in my solution, so in my sample, I have created a Web Templates folder, and then added the BLANKENT element.
NOTE: The Elements folder MUST share the same name as the WebTemplate name property. - Open the empty Elements.xml and add the <WebTemplate /> element block.
- Copy the default.aspx and ONET.XML files from the STS site definition location at 14\TEMPLATES\Site Templates\STS. We will customize the ONET.XML in the next section. Open the properties for each file and set the Deployment Type to ElementFile. This ensures the files are deployed with the Element when included in a Feature.
- By default a new feature is added to the solution for you automatically when a new element is added to the solution. Rename and edit the feature as appropriate. Select Farm for the scope to deploy the WebTemplate to the entire farm, or Site for a sandboxed solution.
Customize the ONET.XML
At this point, you have a working WebTemplate solution that will deploy the identical site to the out-of-box Blank Site, however the ONET.XML supporting the STS site definition contains 3 configurations – essentially 3 separate site templates and can be simplified before customizing.
In the following sample, I have trimmed the ONET.XML to the essentials for a single Site Template, and added references to the <SiteFeatures /> and <WebFeatures /> elements to include the SharePoint Standard and Enterprise features. I have left the top-level navigation bar, and the default page module intact, but removed all other extraneous markup.
Summary
The last step is to develop additional features within your solution, and custom the ONET.XML to include Site or Web feature references for your custom features. Since the Feature framework was introduced in SharePoint 2007 it has been considered a best practice to keep the ONET.XML in Site Definitions as simple as possible and isolate custom functionality into Features. This certainly applies to site templates created with the WebTemplate element features.
Although web templates identify a base template which must be a site definition, using the blank configuration element of the out-of-box STS site definition provides a clear slate for almost every type of site you may want to create. In my mind, WebTemplate features are the *gold standard* for custom sites in SharePoint 2010, and should be the preferred customization model for all but the most extreme cases where site definitions provide the only approach to solving a problem. For the majority of developers, WebTemplate features will be the only thing you will need.
For more information on when to choose between a WebTemplate and a Site Definition, see Site Types: WebTemplates and Site Definitions on MSDN.
Directly from - http://msdn.microsoft.com/en-us/library/ms474369(v=office.14).aspx
ReplyDelete"A Module element can only be in an Onet.xml file that is part of a site definition, not in an Onet.xml file that is part of a web template."
You have a module element in your example which shouldn't be.
Documentation is wrong - try downloading and testing my sample without it :) Without that module, the default page for the site won't be provisioned. Modules do work in web templates.
DeleteIt is a better approach to put module elements in features and then activate the features in the web template to keep the schema as simple as possible. For other types of module elements like master pages, styles, etc., I do use features.
I only use this technique for the default site page, so the web template can be tested stand-alone before I start adding my custom feature activation's. I will even include this module if I have a feature provisioning an alternative start page, so that if the feature is deactivated, I can revert the default page back to the original.