Who likes creating SharePoint site definitions from scratch? Well, it's not my favorite part of the SharePoint development either. An initially good idea of setting up your whole site through an XML file, received implementation and support far from being perfect. That quickly lead developers to look for alternative ways of defining and provisioning sites, primarily through the SharePoint API. A simple ONET.XML with beefy code-packed features became de-facto standard. What was supposed to be a template became compiled code. I was hoping SharePoint 2013 would at least attempt to do something about it…
Tasked with creating a few publishing portal site definitions, I was unpleasantly surprised to find out that any attempt to use my new site definition to provision a site collection root results in both Global and Current Navigation switched to "Managed Navigation" mode, while I needed it to stay in the good old "Structural Navigation" one. This mode is new to SharePoint navigation, so in hopes that Microsoft did not forget about the ONET.XML admirers, I went to look at the Portal Navigation Properties feature, a.k.a. "541F5F57-C847-4e16-B59A-B31E90E6F9EA". You typically use it to affect navigation settings in a following manner:
<!-- Per-Web Portal Navigation Properties -->
<Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
<Properties xmlns="http://schemas.microsoft.com/sharepoint/">
<Property Key="InheritGlobalNavigation" Value="true"/>
<Property Key="InheritCurrentNavigation" Value="true"/>
<Property Key="IncludeSubSites" Value="true"/>
<Property Key="ShowSiblings" Value="true"/>
<Property Key="IncludePages" Value="false"/>
</Properties>
</Feature>
Those property keys have never been explicitly documented on MSDN, but anyone who ever created a site definition is pretty familiar with them, thanks to numerous blogs and standard SharePoint site definitions. I assumed that with the introduction of a new navigation mode, a new property to switch between the two would also be provided in the latest version of the Portal Navigation Properties feature. The only sure way to find out was to look into the source of Microsoft.SharePoint.Publishing.dll, as it contains the feature's event receivers. Indeed, it turned out to expect over a dozen properties:
That's definitely more than I knew about, but not helpful in my particular case. Why does it switch to "Managed Navigation" mode? The answer was at the very end of the feature receiver code:
if (publishingWeb.Web.Site.CompatibilityLevel >= 15)
{
FriendlyUrlUtilities.ActivateManagedNavigation(publishingWeb.Web);
}
That's it - if your site is SharePoint 2013-compatible (which it certainly is), you get switched to "Managed Navigation" unconditionally, and there's nothing you can do about it! This is where I realized that nothing really changed in Microsoft's perception of ONET.XML, and went back to frankensteining my site definitions with code by creating a feature to set the navigation mode through API:
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb web = properties.Feature.Parent as SPWeb;
WebNavigationSettings navigationSettings =
new WebNavigationSettings(web);
navigationSettings.GlobalNavigation.Source =
StandardNavigationSource.PortalProvider;
navigationSettings.CurrentNavigation.Source =
StandardNavigationSource.PortalProvider;
navigationSettings.Update();
web.Update();
}
Happy SharePointing…
Tasked with creating a few publishing portal site definitions, I was unpleasantly surprised to find out that any attempt to use my new site definition to provision a site collection root results in both Global and Current Navigation switched to "Managed Navigation" mode, while I needed it to stay in the good old "Structural Navigation" one. This mode is new to SharePoint navigation, so in hopes that Microsoft did not forget about the ONET.XML admirers, I went to look at the Portal Navigation Properties feature, a.k.a. "541F5F57-C847-4e16-B59A-B31E90E6F9EA". You typically use it to affect navigation settings in a following manner:
<!-- Per-Web Portal Navigation Properties -->
<Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
<Properties xmlns="http://schemas.microsoft.com/sharepoint/">
<Property Key="InheritGlobalNavigation" Value="true"/>
<Property Key="InheritCurrentNavigation" Value="true"/>
<Property Key="IncludeSubSites" Value="true"/>
<Property Key="ShowSiblings" Value="true"/>
<Property Key="IncludePages" Value="false"/>
</Properties>
</Feature>
Those property keys have never been explicitly documented on MSDN, but anyone who ever created a site definition is pretty familiar with them, thanks to numerous blogs and standard SharePoint site definitions. I assumed that with the introduction of a new navigation mode, a new property to switch between the two would also be provided in the latest version of the Portal Navigation Properties feature. The only sure way to find out was to look into the source of Microsoft.SharePoint.Publishing.dll, as it contains the feature's event receivers. Indeed, it turned out to expect over a dozen properties:
InheritGlobalNavigation | bool |
InheritCurrentNavigation | bool |
ShowSiblings | bool |
IncludeSubSites | bool |
IncludePages | bool |
GlobalIncludeSubSites | bool |
GlobalIncludePages | bool |
CurrentIncludeSubSites | bool |
CurrentIncludePages | bool |
GlobalDynamicChildLimit | int |
CurrentDynamicChildLimit | int |
OrderingMethod | Enum: "Automatic", "ManualWithAutomaticPageSorting", "Manual" |
AutomaticSortingMethod | Enum: "Title", "CreatedDate", "LastModifiedDate" |
SortAscending | bool |
IncludeInGlobalNavigation | bool |
IncludeInCurrentNavigation | bool |
That's definitely more than I knew about, but not helpful in my particular case. Why does it switch to "Managed Navigation" mode? The answer was at the very end of the feature receiver code:
if (publishingWeb.Web.Site.CompatibilityLevel >= 15)
{
FriendlyUrlUtilities.ActivateManagedNavigation(publishingWeb.Web);
}
That's it - if your site is SharePoint 2013-compatible (which it certainly is), you get switched to "Managed Navigation" unconditionally, and there's nothing you can do about it! This is where I realized that nothing really changed in Microsoft's perception of ONET.XML, and went back to frankensteining my site definitions with code by creating a feature to set the navigation mode through API:
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb web = properties.Feature.Parent as SPWeb;
WebNavigationSettings navigationSettings =
new WebNavigationSettings(web);
navigationSettings.GlobalNavigation.Source =
StandardNavigationSource.PortalProvider;
navigationSettings.CurrentNavigation.Source =
StandardNavigationSource.PortalProvider;
navigationSettings.Update();
web.Update();
}
Happy SharePointing…
Comments
Post a Comment