Inconvenient Sandboxed Web Templates and Navigation
Web Templates are the new recommended approach for templating sites. Combined with Sandboxed Solutions they empower power users and offer them great flexibility and productivity. There is however one inconvenience with regard to how SharePoint Navigation Providers deal with Sandboxed Web Templates.
Web Templates are the way to go
Back in SharePoint 2007 we had two options for templating sites: we could either save sites as templates which resulted in unmaintainable STP files or create Site Definitions and deploy them using Solution Packages. In both scenario we were locked and unable to change the template. Even though Site Definitions were deployed using solutions, changing them after sites have been created off them was not allowed and creating another Site Definition was the only option. Unfortunately, since Site Templates didn’t support Publishing Sites, creating Site Definitions was the only option in SharePoint 2007 if you had to offer the publishing capabilities in your template.
With the release of SharePoint 2010 Microsoft introduced Web Templates – a new, highly flexible concept for templating sites. Because there is no reference between the created site and the Web Template itself modifying Web Templates is not a problem. There is no restriction to the capabilities supported by Web Templates so you can use them with any kind of sites that you want. Additionally Web Templates can be deployed on both Farm and Site Collection level using a Farm or Sandboxed Solutions and that allows you to use Web Templates with SharePoint Online. And although Web Templates have some limitations, they are the recommended way of templating sites in SharePoint 2010.
Sandboxed Web Templates
Web Templates can be deployed on specific Site Collections only as opposite to the whole Farm and with that they can be deployed using Sandboxed Solutions. This offers great flexibility to IT-Pros, developers and power users. Sandboxed Solutions require virtually no maintenance from IT-Pros. Site Templates created by power users are saved as Sandboxed Solutions and with some effort they can be extended by developers with new functionality. Distributing Web Templates using Sandboxed Solutions allows you to truly benefit of the customization capabilities of the SharePoint 2010 platform and create business solutions that are usable both on-premise and on-line.
Although there is no difference in building Web Templates for the Sandbox and Farm Solutions, there are some differences in how SharePoint provisions contents of Sandboxed Solutions. One of those difference impacts using Web Templates for templating sites.
Inconvenient Sandboxed Web Templates and Navigation
Imagine we had a Web Template distributed with a Sandboxed Solution. The Web Template is a template for a Publishing Site used for creating subsites on a Publishing Site Collection with anonymous access. As soon as you create a subsite off the Web Template what you will see is that the link to that particular site is automatically added to the navigation.
This works as expected given we are authenticated and have access to pages that haven’t been published yet. Unfortunately if you access the same site as an anonymous user you will still be able to see the link to the newly created subsite that hasn’t been published yet!
It’s not that hard to imagine that as soon as you click this link you will see a 404 error: after all the Welcome Page of that subsite hasn’t been published yet and therefore is not available for anonymous users.
If you now go back to the newly created subsite and check in the Welcome Page as draft, the link to that subsite will disappear from the navigation for anonymous users – just as you would expect it to in the first place.
This odd behavior has partly to do with the fact how Sandboxed Solutions provision files by default. Whenever you provision a file using a Module in a Sandboxed Solution that file will remain checked out and there is no version checked in at all. What’s surprising is how SharePoint Navigation Providers deal with that scenario. Instead of hiding the link to the website, the link is displayed in the navigation and if the content author isn’t careful enough, such “broken” links will appear to anonymous users.
Sandboxed Web Templates and Navigation – better together
Provisioning files as checked out without any version checked in is how Sandboxed Solution handle Modules by default. Unfortunately there is now way to change this behavior declaratively and with that there are two solutions that you can choose from.
Teach, teach, teach
One approach that you could choose for is to stick with the standard SharePoint 2010 behavior and educate content authors to always check in the Welcome Page after creating a subsite. This is useful not only to prevent broken links to be displayed in the navigation but also to allow other members of the content authoring team to edit the contents of the Welcome Page. The great benefit of this approach is that you stick with the standard approach and instead of altering it or introducing custom solutions you educate users about the issue and potential consequences.
Check it in… automatically
Another choice that you have is to add a Feature Receiver to the Feature responsible for provisioning the Welcome Page and have it automatically check in the Welcome Page as a draft. With that the Welcome Page remains invisible to anonymous/unprivileged users and no additional effort is required from the content authors. The only downside is that custom code is required and is something that cannot be created by power users themselves and would need to be maintained and tested in the future.
As you can imagine both approaches have their pro’s and cons. It’s important to know that neither of them is better than the other and which one you choose depends a lot on your team and requirements.
Web Templates are the new recommended way for templating sites in SharePoint 2010. Unfortunately when used with Sandboxed Solutions, when you create a subsite off a Web Template, a broken link is added to the navigation for all users. This inconvenience can be solved by either manually checking in the Welcome Page of the subsite or using custom code and the choice for either approach should be made based on the requirements of the particular scenario.