Recently, I stumbled across a annoying issue when building a new Site Definition for a SharePoint portal.
The Site Definition contained several document libraries and some features. One of these features interacted with the new document libraries. Within the attached feature receiver it sets some properties on the document libraries for the versioning of the documents.
I knew the entries in the onet.xml would be processed in sequence, but to my surprise the lists properties where not set. When debugging the feature receiver I discovered the lists were not there yet. But the List section in the onet.xml was put before WebFeatures section.
After some more debugging and searching the internet I came across an article describing the order in which the onet.xml is processed.
The appears the onet.xml sections are processed in a fixed way. And only the entries with in a section are processed in the order they are put in the file.
SharePoint provisions in the following order:
- global onet.xml
- SPSite scoped features defined in onet.xml, in the order they are defined in the file.
- SPSite scoped stapled features, in quasi random order
- SPWeb scoped features defined in onet.xml, in the order they are defined in the file.
- SPWeb scoped stapled features, in quasi random order
- List instances defined in onet.xml
- Modules defined in onet.xml
Right. My idea of using the onet.xml to contain all parts of the site and to use a generic feature for all site definitions went down the drain.
I have solved the problem by adding an additional feature for each site definition, which contains the document libraries to be created and the feature receiver. It works fine, but I would have preferred to keep it all down to the onet.xml and one feature.
The full article: Shared Points for SharePoint : Site Provisioning Order