Introduction
As you might know, there are multiple different techniques for provisioning new sites in SharePoint. SharePoint deployments always consist from at least one site, which provides functionalities for the end users. There’s multiple ways to create these sites and to customize them based on customer requirements. In this blog post we concentrate models, which support strict versioning model. Meaning that the sites are not built directly to production environment using SharePoint Designer or browser rather deployed using solution packages.
Before we get started, let’s first concentrate on getting the terms right. There’s multiple different terms used when we reference definitions, which are used for creating new sites. Here’s the clarification on the most used one’s and how they should be used.
Site Template
Why is the provisioning model such an important thing? – since overall usage models in SharePoint, especially for larger companies, are not just based on individual web parts, which are used to bring additional value over the out of the box site structures. In larger project, the productivity of the individual end users and the editors plays role for designing correct model, since we want to have as good and consistent user experience provided through out the farm.
Let’s have a real life example of one global intranet, which had 50 part time content editors and more than 700 sites in site hierarchy for each of the country sites. There’s 10 different site types, which should provide the same functionality where ever they are located. Since there’s quite a lot of content to be created and managed, it’s better to create specific templates compared to use feature stapling and browser customizations. You can only image the time spend modifying each site using browser and even though there would be documented instructions, most likely most of the sites would look little bit different than other. By providing 10 configured web templates, which will have all templates and web parts as defined by corporate communication, intranet will have consistent user experience and content editors can easily extend the sites as required.
Key point on the site provisioning is to automate something which would be done manually by site authors. Business case can be calculated quite easily from the amount time required for each site to be configured based on the company guidance. There doesn’t have to be that many sites created, before the investment for customization is worthwhile.
I’ve been still seeing demos and real production environment where the end users or content authors are forced for example to active features manually in certain order to configure the site as planned. This should not be the case, since it also increase risks of breaking up the sites by for example activating accidently wrong features.
Other consideration is obviously the implications due the customizations. Certain options available can cause implications on maintenance and upgrade processes, which will impact on the overall costs included in the deployment. Luckily in SharePoint 2010, we now have the new Web Template option, which will help to address these issues.
So key advantage of automating the site provisioning to save time and ensure consistent end users experience throughout the particular deployment. This is not only important for WCM sites, but also for other site types to provide consistency.
Different site provisioning methods in SharePoint 2010
There is four or five different main models for site provisioning in SharePoint 2010, depending what’s considered as individual models.
•Feature stapling
•Site templates
•Web Templates
•Site definitions
•Provisioning provides
•Custom code (mainly for automated processes)
We’ll cover each of the options in high level to consider the different advantages and disadvantages in each of them, except the full custom code option, which obviously can be anything. These options will concentrate on different ways to control what’s provisioned when end users uses the out of the box Create functionality.
Feature stapling
Primary purpose of the feature stapling is to extend and customize existing site definitions. Usually these are used to provide some custom functionalities for the out of the box site definitions, but technique is definitely available also for the custom site definitions.
Since it’s not supported to change the onet.xml file of site definitions after it has been used in environment, feature stapling is quite commonly used also to provide versioning for the already deployed custom site definitions. You can modify the stapling definitions to different site definitions also afterwards. It’s important to remember that stapled features are only activated on provisioning time, so if there’s any existing sites already provisioned, those won’t be affected automatically just by deploying new stapling definitions.
Biggest downside with the feature stapling is that we can only extend the existing site definitions, we can’t provide new. This can be an issue for example when you’d like to have WCM templates created for multiple different site purposes. Also the fact that stapled features are activated before the module element or list elements in onet.xml file has been provisioned, can cause issues unless you use some workarounds. Notice also that feature stapling is only supported when site definitions are used, it doesn’t work if you are provisioning sites using site templates or web templates, even though these both options refers to root site definition.
Site templates
As you might know SharePoint 2010 has changed the functionality used for saving existing sites as template. In 2007 version when site was saved as a template, specific STP file was created, which could not be modified in anyway. In 2010, when we save site as template, SharePoint generates full fledge solution package (WSP file), which can then be moved between any environment containing all site level objects, like libraries and optionally also content.
There are two key improvements in feature framework scheme, which have made this possible. These are WebTemplate element and CustomSchema attribute for ListInstance elements. These two options will make it possible to provision sites using alternative xml definitions, but then refer back to out of the box templates. Key point is that we use alternative definitions during provisioning, but all object references will be associated to out of the box types.
One of the biggest downsides with the site templates is the fact that they are not supported when publishing features are enabled. This is also the reason why we hide the link from the site settings page to avoid anyone to use this functionality. Obviously if you know the aspx page name, you can access the page and save the site as a template also when publishing features are enabled. This is however not supported. What does that mean? – just because you can… doesn’t mean you shouldn’t. Publishing sites have complex references and dependencies, which have to be carefully defined even for site definitions. This is not supported (and link is hidden) so that inexperienced users wouldn’t break intentionally their deployments.
One of the consideration with the site templates is also the fact that unless you import them to Visual Studio and modify its settings, they are only available on site collection level (site collection scoped feature), which means that to be able to have the template available from multiple locations, we’ll have to either deploy the site template as sandbox solution to multiple site collections or deploy it as full trust solution and then activate the particular feature in site collections to have the template available.
Web Templates
We’ll concentrate more detailed on the Web templates in later chapters, but basically with the web templates in this case, we refer to manually created WebTemplate elements in the Visual Studio. We need to create two files for each of the web templates. Other one is empty element (is VS2010 is used) for defining the actual WebTemplate element and other one is completely similar onet.xml file as for site definitions, with few exceptions, which we’ll cover little bit later.
When we have our web template created, we’ll associate the element file to feature, which will be responsible of deploying the web template. WebTemplate element is supported in two scopes, which are Farm and Site. This means that we can deploy the web templates to be available either throughout the farm or based on site collection scoped feature activation. It’s important to notice that dispute the fact that we’d be using site collection scoped feature for deployment, we can still deploy the web template using farm scoped feature. This would for example give us possibility to filter the options available from the Create site functionality, based on feature activation status.
One big advantage of the web templates is the fact that since they are feature based and there won’t be any files stored in file system, those are completely supported usually by the cloud services, like MS Online (BPOS). Support obviously varies based on the cloud service types, like in MS Online case, if the service is dedicated or standard. These usually mean for example differences on the support for full trusted solutions or only sandbox solutions.
One really important advantage with the web templates compared to the site templates is the fact that we can utilize the publishing features in web templates. This provides us possibility to create new site provisioning options to be available from the Create site functionality, even though we would be creating new publishing feature based sites.
Site definitions
Site definitions are the classic xml files, which are for example used to provision out of the box sites. Many of the developers learned to create these in 2007 version, since they are very powerful and there were almost no other options available for introducing new options for the Create site functionality. As mentioned earlier site definition consists basically from two different files: WebTemp*.xml and onet.xml files.WebTemp*.xml defines how the site definition is visible for the end users and the onet.xml file contains the definitions for the actual site provisioning.
We can only deploy site definitions using farm solutions, since files will be located in the file system. They are also by default available throughout the farm in every application, unless we limit the visibility either using AvailableWebTemplates attribute for publishing sites or more generally available VisibilityFeatureDepency attribute in the WebTemp*.xml file. Since we won’t be concentrating on site definitions in this blog article, I won’t be covering these options more detailed.
Key change in the site definitions for the 2010 version is that if you have site collection scoped feature associated to site definitions under the SiteFeatures elements, those features are not activated, if you create sub sites. In 2007, also these site collection features where activated also for sub sites. This could be an issue when for example you want to add new Events site under corporate intranet and you’d like also for example content types to be created, when site is provisioned. There are workarounds for this, which are declared later in the web template creation chapters (same workaround applies for site definitions).
Whenever we create site based on any site definitions SharePoint stores the site definition identifier information to SPWeb.WebTemplate, SPWeb.Configuration and SPWeb.WebTemplateId properties. These are critical properties in the SharePoint platform, which have to be set for each of the sites. Let’s come back to this in following chapters with detailed web template information.
Biggest challenge with the site definition is that we are not allowed to change the onet.xml file after it has been used to provision any sites in the environment. This is just not supported. There are certain scenarios, which don’t impact the existing sites and it might seem that update didn’t cause any issues, but just because it didn’t hurt the first time, should you do it again? – no. This is one of the classical rules of SharePoint development, like the fact that don’t touch the databases directly.
Already in 2007 version there was numerous approaches to go around the fact that onet.xml file should not be updated. Most classic one, is the so called “minimal site definition approach”, where we all possible customizations to features, which don't’ have to be activated in certain order. Let’s not spend too much time on this, but generally out of the box site definitions are actually quite awful examples for custom site definitions (quick summary).
Due these upgradability issues and SLA commitments with the customers, site definitions are NOT supported usually by the cloud services, like in MS Online. It would be simply foolish to impact on the service quality by allowing site definitions to be used, especially since we have at least as good options available in SharePoint 2010, which don’t compromise the service in short or long term.
No comments:
Post a Comment