In the previous post, I promised to try to find time to share additional information concerning the onet.xml and how it can be modified to control other properties of the MOSS site. It took a while, but here we go. Starting from this blog entry, I promise to be more active with writing new stuff to the blog.
This blog entry explains the different options when you configure the standard publishing features in onet.xml. If you are interested concerning the navigation options for the MOSS sites, check the previous post with details concerning the different options on configuring the navigation settings within the site.
If you have created your own site definitions based on the out-of-the-box reference implementations, you have most likely noticed following feature and it’s configuration options.
The feature ID defined in the onet.xml refers to the Publishing feature stored by default in the folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\Publishing. Feature.xml file for the feature looks like following.
Description=“Enable Publishing in a web.“
So when the site is created based on this site definition, the Microsoft.SharePoint.Publishing.PublishingFeatureHandler class is executed, which manipulates the sites settings using object model, based on the properties defined in the onet.xml. Unfortunately the class used in here is dotfuscated, so we can not check all the possibilities using Reflector. I’ll cover the known properties and their meaning one-by-one with corresponding images from the UI, so you can easily figure out the different meaning and possibilities of each of the properties.
Master page setting
This is the most commonly used property in the feature receiver. You can use it to change choose the master page to be applied to the newly created site. This property configures the WCM master page to be used for the aspx pages, which are based on some page layout and stored in the pages list of the particular site. In this example we set the MBaseMaster.master master page to be used in this particular site.
It’s important to notice, that this setting is actually the same setting as the Site Master Page in the master page settings page. This does not have any affect for example for the list aspx pages, since those pages use the system master page by default. I’ll write separate post concerning the system master page and how it can be changed from the onet.xml easily.
Welcome Page Url
This property defines the welcome page to be used for the site. Welcome page means the page, where the user is redirected when the site’s url is requested. By default when the sites url is requested (for example http://portal/site1/) we redirect the user to the default.aspx page, as in this example. Good example of the welcome page usage, it the Wiki sites. The Wiki site uses the welcome page setting to redirect the user directly to the wiki list stored in the site.
In user interface, the welcome page can be set using the Welcome page link, which can be found under the Look and feel section in the site settings page.
On the welcome page setting page, you can browse to the file you want using standard asset picker.
Page List Url
<Property Key="PagesListUrl" Value=""/>
You can use this property to define some other list to be used as the pages library. By default the WCM pages are stored under pages list (http://portal/site1/pages), but if you like, you can change the setting by adding the list name in to this property.
Available Web Templates
This setting can be used to filter the site definitions to be shown in the Create Site page. So using this property, you can limit the different options to be shown to the site hierarchy manipulators. If you have multiple different site definitions used in your portal, the portal managers might have difficulties of understanding the different templates available. It’s also important to realize that if there’s multiple appications installed on the same MOSS farm, all of the installed site definitions are shown by default in the Create Site page, regardless of the application used..
So if property is left empty, all of the installed site definitions are available. Multiple templates can be configured to the property using following syntax. In this example there would be two different site definitions available.
From user interface, you can configure the same setting from the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.
Using this functionality, you can manually select the shown site definitions. In this case also, all of the site definitions installed on the MOSS farm are shown, regardless of the particular application.
Following image is from the Create Site page, when only one site definition is configured to be shown. In this case, we are under the Projects Catalog site, and based on the portal design, it’s decided that you should only create Project sites under it.
Available Page Layouts
This property is similar as the AvailableWebTemplates, but it applies on the page layout level. Using this property, you can filter the page layouts to be shown in the Create Page functionality. Since there might be tens of different page layouts created on on portal, it’s convenient to filter the options to be shown for the portal editors. If you have multiple page layouts available for the particular site, the different layouts are lsited in the same property, but separated using colon.
From the user interface, the similar would be configured using the the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.
So when the configuration has been done for the site and you select Create Page from the Site Actions menu, we can see only the configured page layouts to be shown.
<Property Key="SimplePublishing" Value="true" />
Possible values for this property are True / False. This actually affects on the approval functionality concerning the sites pages list… If property is set as false, the pages list has require approval setting activated and there for all of the changes done to the pages in the sites, have to be approved using separate process. If the property is set as true, the content is instantly published to the portal.
Using these settings and properties, you can fairly easily control the different publishing settings for the particular site. On the upcoming post, I’ll declare the detailed steps to write a custom feature receiver to be able to configure also those properties, which are not by default available.
Hopefully this helps.