When is it right to customize a site definition?

Question

In some scenarios there is a need for being in as much control of the site provisioning process as possible.

In some senarios there is a good solution to customize site definition by customizing the onet.xml file to define site definition, navigational areas, list templates, document templates, configurations , modules, components.

When is it right to customize a site definition and when is it completely wrong?

Answer 1

It's right to customise it when your business requirements state the need to do so ;)

I've recently also came across the concept custom provision providers, which allow you to control the site provisioning process from managed code, allowing very granular control over your site creation.

There is also the possibility to just create a site template (.stp) file (now a .wsp in 2010?) from a Site Definition if you do not require such level of control & detail over the site provisioning process, which is very simple to do but does have it's drawbacks such as limitations on size of the template (when storing contents), and deployment/scalability issues.

So, as for your question as to when is it right and when is it wrong, there are different methods of site provisioning and creating and the key thing that defines which one is right is when your business requirements says so.

Answer 2

There was a big discussion in the SharePoint community a while back on site definitions. The conclusion was that things tend to work out better if you use:

• a minimal site definition
• Features which are stapled to your minimal site def

This gives a more modular implementation of your customizations, though occasionally some things need to be done in the site definition itself.

Here are the main arguments:

• http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=122
• http://www.binarywave.com/blogs/eshupps/Lists/Posts/Post.aspx?List=9c93c708%2De5ce%2D4714%2Dbdea%2D499330361130&ID=162

Answer 3

This topic couldn't have come at a better time for the work I am doing. One of my tasks is to sift through all the .stp that are currently avaialable from the site provisioning page. So the first point is to make sure that only individuals that should have this right to create templates have permission ot the site template gallery. In my case all authenticated uses had full control to create .stps and this has caused some chaos. Users have no idea what they are selecting to create their sites. The second thing that I have noticed is that you can't version stps in the site template gallery. We also didn't provide good descriptions to tell the users more about what the template does. This should be a standard best practice. This is where a wsp file would be handy as you can upgrade accordingly and control the chaos with a simple deployment.

I love the approach that I learned from some of Bjorn Furuknaps principles:

1. Web Based Prototype of site
2. Export to STP
3. Extract Config from stp
4. Build WSP
5. Deploy Test

Step 3 could get a bit hairy so as a Business Analyst it is wise to be there during the prototype step as the stp file once extracted could be a bit hairy.

Answer 4

For custom site definition, you can either modify the ONET.XML file or use Stapling to stapling a FeatureID to a site definition. I will prefere an combination of this. The site definition will only reflect new site that will be created. Sites alredy created will not have feature activated on it and wil require a maintenance process. A maintenace process will activate new feature to all existing sites. This can be done with creating a custom STSADM extensions the will run through all sites and subsites, validate if the feature's is there on the SPWeb.

Answer 5

Simple answer. Never ever ever customise an existing site definition! You should create your own and use Features/Solutions for deployment.