Site Definitions vs Site Templates and Site Provisioning Providers
Posted by Chris on February 25, 2009
Its been a very long time since I wrote anything SharePoint related. Seeing that it has been almost my entire life for the last 8 – 10 months I’ve decided to start writing on SharePoint topics to share my understanding with the world.
I’ve found that one of the biggest points of contention in the SharePoint world seems to be this whole issue of whether to use site definitions or site templates. That’s all very well from a developer and infrastructure point of view but for those people that fall into neither of these categories or newcomers to SharePoint the universal question beckons… “why?”.
Site what? Template huh?
So at this point you may find yourself asking what are these technologies and how are they are even used in SharePoint. They are basically two different, but very closely related, methods to modify a SharePoint site. Now that we know the very basic reason for their uses, what are the differences?
What is a Site Definition?
To understand what a site definition physically is you first need to understand some extremely basic facts about how SharePoint operates. Very simply put, all user content on a SharePoint site is located in a SQL Server database. All the code and the pages that are used to administer and render the SharePoint site are stored as physical files on the web server. A site definition exists as physical files on the web server and defines, through the use of SharePoint’s XML schema (known as CAML), the lists, columns, features etc. that should be created/activated when a site is created.
Creating site definitions involves a fairly good understanding of CAML. Generally speaking, it requires the knowledge of an adept SharePoint developer (not the same as an adept ASP.NET developer… but thats an argument for another post) to create these site definitions.
[Warning: Personal Opinion Ahead]
Software developers tend to be advocates of site definitions. It fits with the ‘perfect world’ outlook most software developers tend to apply to everything they do. By not allowing change it means a software developer can request a department to ‘fully analyse’ their department and not come back until they have ALL their requirements listed. This is the usual practice of a software developer ‘handling’ change by not allowing it altogether. [N.B. I am a software developer and in my younger days have been guilty of this too so no hate mail about this comment.]
What is a Site Template?
If you can understand what a site definition is then you’re already halfway there to understanding a site template. A site template is just the modified version of a site definition. These can easily be created as they are just a matter of making changes to a site, such as creation of lists and activation of features, and then saving those changes as a template. Saving those changes is as simple as going to the ‘Site Settings’ area and look for the option ‘Save site as template’ under the ‘Look and Feel’ category (shown in Figure 1).
Generally speaking its recommended by most that you try to stick to site templates. They are a lot simpler to work with and in the background SharePoint is not binding the site to the site template. I like to think of the site template as a sort of XML script that will build the site automatically for you after the site definition for the site has been declared.
[Killer Reason For Site Templates]
Now don’t quote me on it but I have been told that Microsoft will not provide support for custom site definitions which may break in any future versions of SharePoint and will only provide support for the out-of-the-box site definitions. Assuming this is this case then I think that unless you are creating a product this is the “end all and be all” of reasons as to why you would choose a site template, based on an out-of-the-box site definition, over a custom site definition.
Side Question (For those perdantic enough to realise the question) – If site templates are based off site definitions… aren’t they the same sh*t just on a different day???
I fully agree with the last part of the question… yes they are the same sh*t just on a different day. I know some might argue they aren’t but ultimately they are actually the same technology just used in a different manner. The argument of which one should be used arises from how they have been generally used by people.
As I explained, site templates are in fact modifications of site definitions. The point to remember though is the out-of-the-box site types provided by Microsoft, such as the Blank Site, Team Site, Blog etc., are also site definitions with XML files and all that stuff (you can go visit the entire family in %Program Files%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates). Generally speaking, people that make use of site templates, as a method to manage modifications made to a site, will make the modifications on one of these out-of-the-box site definitions which exist on all SharePoint installations (its important to note this fact), such as the Blank Site.
If you create a site template based off an out-of-the-box site definition it means that you can easily take that site template to another completely different SharePoint installation and, more likely than not, will be able to load it and create sites from it. This in fact is cited as being one of the big wins for using a site template. Deployment can be done by fairly low level admin access and doesn’t require involvement from farm administrators (generally the IT department/infrastructure nerds).
I Still Don’t Get Why It Matters!!!
So why does it even matter whether we use site definitions or site templates, isn’t it like an argument between white bread and brown bread… they’re all bread? Why do I, as a newcomer to development/infrastructure/project management/business analysis/<insert random occupation description here> of SharePoint infrastructure, care whether site definitions or site templates are used? Well because depending on which method you use you could be in for a whole world of hurt in the future.
The Problems With Site Definitions
Site definition once deployed and in use on a SharePoint installation can’t be modified. Any attempts to add to the site definition is going to result in breaking the current sites that have been created from the current site definition. What this means is that if you do intend to use a site definition, you better be pretty damn sure that when you deploy it for use, thats the final version and you’ll never need to update it again.
The Problems With Site Templates
So after hearing how restrictive site definitions are you’re probably thinking “problem solved… I’ll use site templates” but there are problems with using that too. The greatest argument in the case for site templates, their simplicity, is also their greatest weakness… they are too simple. Their simplicity causes them to be less efficient, can’t be feature stapled (another post for another day) and as they are not created within a development environment make them hard to debug for a developer, if problems arise.
So Everything Sucks!
The current problem I have with IT practices now a days is that there seems to be a general lack of thinking and common sense and it appears accepted ‘best practices’ are needed everywhere. The problem with this is the fact that in real life, and especially in cases where software development is the solution, there is rarely one best recipe.
If you have a situation where the site definition will not change e.g. a SharePoint product for sale, then I’d say to use a site definition. If you are developing in-house templates that will be added to by end users and you’ll be forever upgrading the site, then use a site template. With both these options in mind there is a third solution that can provide a solution to the weaknesses of both situations and is a sort of hybrid of the two.
Custom Site Provisioning Provider to the Rescue!!!!
“Site provisioning… whats that?” I hear you say through the electronic ether. Provisioning a site is a fancy way of saying “creating a site”. Why they use the word provisioning, I don’t know. Its probably for a good reason but I like to think that its something to do with software developers wanting to have a fancy new words to throw around.
A site provisioning provider is a piece of code that is run by a site definition when a new site is created. By default SharePoint performs the provisioning actions of a new site. These actions can include creation of lists, activation of features etc. and, most importantly, telling the site which site definition it should be based off. This is important because by declaring the site definition to base the site off you inevitably bind the site to that site definition.
Now that you understand what a site provisioning provider does its time to explain how we can use this concept to our advantage. Generally we would like to use a site template to do most things – they are simple to create and just as easy to deploy. Site templates also provide us with a way to easily deploy a new custom site to a completely different SharePoint installation, provided they are based on an out-of-the-box site definition.
With the above facts in mind, by creating a site definition declaration with a custom provisioning provider, we can tell the SharePoint very specifically how to create the site. This includes which site definition we should base the site off. It is very important to note that there is actually a separation between the declaration of a site definition and the onet.xml which declares all the parts of the site definition. The reason this is so important is that by use of the site provisioning provider we can intercept the call to use the onet.xml. Its through this interception that we can then request the site provisioning provider to instead use a different site definition/onet.xml – specifically an out-of-the-box site definition/onet.xml. This means that we are, in a very round-a-bout way creating something very similar to a site template but from code. Recall I said I liked to think of a site template as an XML script, well now instead of having an XML script to build the site we can create code to build the site.
After the above paragraph you’re probably sitting there confused with the question “but if my site definition is being called how is it that I end up with a site set up like a template?” and that is a fair question. As I described above, its important to realise that there is a difference between your declaration of the site definition and the actual files that describe your site definition. By using the site provisioning provider we no longer need the file (onet.xml) that describes your site definition as we instead use the one provided by one of the out-of-the-box site definitions. Its similar to using a map to find your way to a place but along your journey there are road works and signs for a detour. Even though the map tells you to go one way, you end up following the detour signs. The site provisioning provider is the detour sign.
By basing the new site off an out-of-the-box site definition as opposed to a custom site definition we have effectively decoupled ourselves as a dependency for any future site templates that may be based off us. Additionally we can add to the code and we won’t break any sites that have already been created from using the site provisioning provider. As you can see, in effect, we’ve turned the standard site definition into a sort of site definition/site template hybrid. It uses the same concept of a site template but built within the framework of a site definition.
I think its pretty obvious to see the implications of using site definitions and site templates and how they both have their place. The argument over which one should be used is pretty redundent and through the use of a site provisioning provider can in fact be avoided altogether. I’ve given a basic understanding of why the argument exists and how site provisioning providers can help solve the issue but if you’re looking for details on how to create one you can find details at both the following posts.