Vesa "vesku" Juvonen : Web Content Management

Controlling publishing features from onet.xml

sonofthesun — Sun, 14 Oct 2007 21:31:40 GMT

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.

Introduction

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.

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

<Property Key="ChromeMasterUrl" 
   Value="~SiteCollection/_catalogs/masterpage/MBaseMaster.master"/>

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

<Property Key="WelcomePageUrl" 
    Value="$Resources:cmscore,List_Pages_UrlName;/default.aspx"/>

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

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Project#1"/>

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.

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Generic#1;
            *-Microsoft.Intranet.POC.News#1;"/>

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

<Property Key="AvailablePageLayouts" 
   Value="~SiteCollection/_catalogs/masterpage/MGenericBodyOnly.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageLeft.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageRight.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageTop.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericLinks.aspx:
          ~SiteCollection/_catalogs/masterpage/MSectionPage.aspx"/>

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.

Simple Publishing

<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.

Final words

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.

Controlling navigation options from the onet.xml

sonofthesun — Fri, 23 Mar 2007 11:28:00 GMT

During past weeks I have been creating few customer POCs to demostrate the excellent WCM features of the MOSS 2007. Since the MOSS publishing features are deployed over the WSS using standard feature framework, we can configure the provisioning of the sites directly from the onet.xml. In this blog entry, I'll declare the concepts behind this possibility and the possible properties, which can be set.

Introduction

If you have played around the onet.xml files included as out-of-the-box in the MOSS (Publishing template etc.), you have most likely noticed the publishing navigation feature dependencies in the WebFeatures element as in xml block below.

<WebFeatures>
     ...
     <Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
          <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
          <Property Key="InheritGlobalNavigation" Value="true"/>
          <Property Key="ShowSiblings" Value="true"/>
          <Property Key="IncludeSubSites" Value="true"/>
          </Properties>
     </Feature>
     ...
</WebFeatures>

So what does this really mean? Basically we are making a binding to publishing navigation feature and configuring it by using properties, which the handler is capable to handle. So the ID given in the onet.xml is a reference to NavigationProperties feature, which can be found from the following folder (by default):

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\NavigationProperties

And the feature.xml file from here contains following information:

<Feature Id="541F5F57-C847-4e16-B59A-B31E90E6F9EA"
               Title="Portal Navigation Properties"
               Description="Set per-site navigation properties."
               Version="12.0.0.0"
               Scope="Web"
               Hidden="TRUE"
               ReceiverAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
               ReceiverClass="Microsoft.SharePoint.Publishing.NavigationFeatureHandler"
               xmlns="http://schemas.microsoft.com/sharepoint/">
               <ElementManifests>
                    <ElementManifest Location="NavigationSiteSettings.xml"/>
               </ElementManifests>
</Feature>

As you can see, ReceiveAssebly and ReceiverClass attributes are set and there for when the actions are performed for the feature, "custom code" is executed. As declared already above, the custom code is aware of some parameters which can be set for the feature and based on these parameters, the receiver handler modifies the SPPublishingWeb object's properties.

Supported parameters

So what are the parameters supported by the NavigationFeatureHandler class and how do they affect compared to settings done from the user interface. I'll declare the supported parameters one-by-one and compare the settings to modifications done from the user interface (Site Actions -> Site Settings -> Navigation).

IncludeInGlobalNavigation, IncludeInCurrentNavigation

Controls the IncludeInGlobalNavigation and IncludeInCurrentNavigation properties of the SPPublishingWeb. In user interface this functionality is controlled by using following options.

InheritGlobalNavigation

This paremeters controls the global navigation options. If set the true, we will get the same outcome by selecting "Display the same navigation items as the parent site".

InheritCurrentNavigation

This controls the inheritance of the current navigation. If set the true, we would get the same results as by selecting the "Display the same navigation items as the parent site" from the user interface (the first option from the picture below)

ShowSiblings

If set the TRUE, the outcome is the same options as the “Display the current site, the navigation items below the current site, and the current site's siblings” option in the user interface (second option from the picture below). Note that the IncludeSubSites and IncludePages parameters also affects to outcome.

IncludeSubSites

This is same as the "Show subsites" option in the user interface. Note that if the current navigation has been set to show the same navigation items as the parent site, this option has no meaning.

IncludePages

This is same as the "Show subsites" option in the user interface. Note that if the current navigation has been set to show the same navigation items as the parent site, this option has no meaning.

OrderingMethod

This option affects to ordering of the navigation items. Note that the final outcome depends also from the AutomaticSortingMathod and the SortAscending properties.

Possible values

Automatic - Sort all node types automatically, and group pages after other types.

Manual - Sort all types manually.

ManualWithAutomaticPageSorting - Sort all types except pages manually. If pages are included, sort them automatically and group them after all other types.

AutomaticSortingMathod and SortAscending

These controls the sorting of the navigation items. Possible outcome depends on numerous other properties, since for example the AutomaticSortingMathod property has only meaning, if the OrderingMethod has been set to ManualWithAutomaticPageSorting.

Note. It's not a typo... it's really AutomaticSortingMathod...

Possible values for the AutomaticSortingMathod property

CreatedDate - Sort items by time of creation.

LastModifiedDate - Sort items by time of last modification.

Title - Sort items alphabetically by title.

Final words

As you can see, you can configure all the same options directly from the onet.xml, as you can do from the user interface. Other thing to notice is the possibilities provided by the Feature Receiver concept, which gives flexible way to execute custom code during the site provisioning (or anytime the feature is otherwise activated).

More information concerning the functionalities declared here can be found from the SDK.

Feature.xml schema
Onet.xml schema
SPFeatureReceiver class - All the FeatureReceiver's are inherited from this class

PS. I'll try to find some time to write similar article concerning the other possibilities of the WCM features (how to limit the page layouts, how to limit the web templates shown in UI, how to configure master page etc.). Stay tuned...

[Update] - The following post with information concerning the other publishing feature configurations has been released. Check the details from here.