Share via

Beware of SPWebProvisioningProvider when using Variations

  • Article

I was doing some research lately on how to have a different "Approvers" group depending on business rule.  To make it simple, the following statement had to be fulfilled:

  • Pages under subsite "/site1" have to be approved by group "Approvers1"
  • Pages under subsite "/site2" have to be approved by group "Approvers2"
  • and so on...
  • We are in a multilingual scenario (i.e.: Variations)

 

we also have custom site definitions for modifying the default welcome page to something else than WelcomeLinks as well as bringing our content types in the library.  So the first thing we looked at was to use SPWebProvisioningProvider that allows to execute a class when provisioning a site.  You can take a look at these URLs for more explanation on SPWebProvisioningProvider:

 

So basically, a site definition reside in the "onet.xml" file and you cannot define a class in that file.  The WEBTEMP*.xml (defined in all "available languages", i.e.: 1033 folder for english) file is the configuration used by the "Create site" interface.  This is where you specify your custom class for provisioning a web.  The first thing your custom class does is to use ApplyWebTemplate() so that the web site is created with the correct template.  Then I was simply modifying the "AssociationData" of the only workflow (Parallel Approval) to update its "Approvers" to my custom one depending on the URL.

 

So far, so good.  Unfortunately, when you create this under a variation, it only works at the source.  The reason for this is that the variation process is only a provisioning mechanism; furthermore, it's only provisioning based on the site definition, not any customization done after.  That includes customization done through a SPWebProvisioningProvider.  So basically, while the "onet.xml" file is called by the variation process, the "WEBTEMP*.xml" isn't.

 

What I ended up doing was to create a feature that contained the same code and added it to my site definition.  If the sites are already deployed, you can look at at using Feature Stapling to do the same thing.

 

In my opinion, the SPWebProvisioningProvider should be a more accurate place to do this code as I want to customize another Feature through business logic.  Of course, I could copy the ReviewWorkflow and create as many of them as I need plus as many Site Definitions for them, which might be okay for SharePoint, but wouldn't be a very reusable approach.  I also find curious that we have a great customizable solution with the provider but it's simply not being called through the variation mechanism.

 

Maxime

Comments