Sometimes it can be usefull to do "post-actions" after a site is created from either a standard or a custom Site Defintion. In WSS 2.0 (and in 3.0) you could usee ExecuteUrl to call a URL post site creation. In WSS 3.0 we now have the so called feature stapling which basically let you "append" features to a Site Defintion without ever touching it. You can even staple feature to the global Site definition and append a feature to all new sites. By using Feature Receivers you could run abritary code to support the site creation process. The only downside is, that when the stapled features is called Lists and Web Parts defined in the ONET.XML is not yet instantiated. It would therefore be impossible to eg. create deafult content in your lists.

A great soultion could be to create a so called Site Provision Provider by implementing SPWebProvisioningProvider. This would give you complete access through the Sharepoint API to the newly created site. Let's see how it's done.

A Site Provsion Provider is made from three components

- The original Site Template you wish to "wrap" eg. "sts"
- A Provisioner webtemp*.xml definition (this is not a "standard" Site Definition)
- An Assembly that implements the SPWebProvisioningProvider class.

The first ting to create would problably be the implementation of the SPWebProvisioningProvider. Lets take a look at that.

Implement SPWebProvisioningProvider

namespace MyProvisioner 
{ 
   public class ProvisionerImpl : SPWebProvisioningProvider 
   { 
       public override void Provision(SPWebProvisioningProperties props)
       { 
         SPWeb web = props.Web; 
         web.ApplyWebTemplate("STS#1");

         //Place your custom code here...
         
         web.Update(); 
       } 
   }
}

We inherit from SPWebProvisioningProvider and override the Provision(...) method. This method is called after the Site has been successfully created. We can then (optionally) apply a WebTemplate. If we fail to do so, the user will be asked to choose a specific template from the standard interface. Below is a picture of how this looks like. In an automated process this is of course not what we want so here we would want to specify a concrete template.

Define a new webtemp*.xml

Next step is to define a webtemp*.xml file. We will name it webtempMyCustom.xml which specifies a number of self explanatory attributes. Just remember to choose a new ID and Name and insert the corrrect class and assembly information.

<?xml version="1.0" encoding="utf-8"?>
<Templates xmlns:ows="Microsoft SharePoint"> 
 <Template Name="TEMPLATENAME" ID="10507">                 
  <Configuration ID="0"
    Title="Extended Team Site"
    Hidden="FALSE"
    ImageUrl="/_layouts/images/blankprev.png"
    Description="My custom provision Site"
    DisplayCategory="Collaboration"
    AllowGlobalFeatureAssociations="False"
    ProvisionAssembly="ASSEMBLYNAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxxx"
    ProvisionClass="NAMESPACE.CLASSNAME" >
  </Configuration>
 </Template>
</Templates>

Define a new Site Template or use an existing

You could now define a brand new Custom Site Definition or, as we do here, rely on an existing one and no furhter steps are neccesary.

An overview of the proces

So this is what happens...

A) Something creates a new instance of the "My Custom STS Wrapper" Site Provisioner template (as if it was a normal Site Definition). This could be dine thorugh code or thorugh the standard Sharepoint "Create Site" interface.

B) Sharpoint will now instantiate a new empty Site and call the Provision method in the ProvisionerImpl class.

C) Now we apply a template (eg. STS#0) and the template is applied...

D) Now the Provision method continue its flow and we do our cutom actions.