Features

Updating the Navigation Settings in a Publishing Site

Andy Burns, , , 2 Comments

I’ve got a brand that I’m activating via a Feature Receiver – it’s a theme and masterpage combination, and I want it to work on Team sites too, so it does actually make sense to do it this way!

Part of the brand is that the tabs have rounded corners, and these don’t work very well with the dynamic drop down menus. You can turn this off in the master page for the site pages, but not for the applications pages. Instead, I figured I’d use a feature receiver to turn off the ‘Show Subsites’ and ‘Show Pages’ in a publishing site.

So, the code I had was this:

if (PublishingWeb.IsPublishingWeb(site))
{
PublishingWeb pwSite = PublishingWeb.GetPublishingWeb(site);
site.Properties[ORIG_PUB_SITES] = pwSite.IncludeSubSitesInNavigation.ToString();
site.Properties[ORIG_PUB_PAGES] = pwSite.IncludePagesInNavigation.ToString();
site.Properties.Update();

pwSite.IncludePagesInNavigation = false;
pwSite.IncludeSubSitesInNavigation = false;
pwSite.Update();
pwSite.Close();
}

However, this didn’t work. To describe the code, first, we check to see if the page is a PublishingWeb. If it is, I record original settings in the site properties (so I can restore them when the feature is deactivated). I turn off those navigation check boxes, update the record on the server and close the object.

After much investigation, I realised that updating the properties was invalidating the PublishingWeb object, somehow, and that my changes weren’t being recorded. In the end I had to change my code to:

if (PublishingWeb.IsPublishingWeb(site))
{
PublishingWeb pwSite = PublishingWeb.GetPublishingWeb(site);
bool showPages = pwSite.IncludePagesInNavigation;
bool showSub = pwSite.IncludeSubSitesInNavigation;

pwSite.IncludePagesInNavigation = false;
pwSite.IncludeSubSitesInNavigation = false;
pwSite.Update();
pwSite.Close();

site.Properties[ORIG_PUB_SITES] = showPages.ToString() ;
site.Properties[ORIG_PUB_PAGES] = showSub.ToString() ;
site.Properties.Update();
}
This worked nicely!

Advertisement
Updating the Navigation Settings in a Publishing Site

Setting the Master Page of a Team Site with a Feature

Andy Burns, , , 5 Comments

Team sites don’t have the Publishing features of MOSS enabled by default, and for WSS systems, well, you don’t have them to enable. Consequently, if you deploy a master page as a feature, you’ll have a bit of fun setting it as the master page.

You can do this though SharePoint Designer, but it’s possible you don’t want your Site owners to have SharePoint Designer, or maybe you just don’t want the hassle of the second step when you provide the master page for a site. Instead, it is possible to set the Master Page through code, and to fire this using a Feature Receiver. This features shows just that – setting the master page through code. Note that to install it, you might well need to make some changes to install.bat. Continue reading “Setting the Master Page of a Team Site with a Feature” →

Setting the Master Page of a Team Site with a Feature

Error: "RootWebOnly='FALSE'" is True…

Andy Burns, , Leave a comment

I wrote a feature to deploy a couple of pages into a Pages library on a site. The idea was that these were search pages, and they’d be going into a Search Center. My feature had an Elements manifest of:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="CustomSearchPages" Url="Pages" RootWebOnly="FALSE" Path="Pages">
<File Url="advanced.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
</File>
<File Url="contentresults.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
</File>
</Module>
</Elements>

Yet when I activated this on my Search Center, the pages weren’t installed. This was weird, ‘cos I’d done nearly exactly the same thing to install my custom Master page. I began swapping bits of the Master Page feature into my Search Pages feature to see if they worked, which at first they didn’t. Then, by accident, I tried installing my Search Pages on my root site, and they did install.

Interesting.

There followed a bit of wild, stab-in-the-dark guessing. I’d seen lots of examples of installing new page layouts, or installing new master pages. These should all go in the root site (or ‘root web’), and so their Module node would specify RootWebOnly="TRUE". I could find very few results, though, where RootWebOnly="FALSE", which is a little unusual on Google. What if the thing that made a module only install on a root site was the presence of a RootWebOnly attribute, rather than the value of it? I tried:

<Module Name="CustomSearchPages" Url="Pages" Path="Pages">

for my module tag. Well, that’s what it turned out to be. I removed the RootWebOnly="FALSE" attribute, and suddenly my pages would install. I guess I was stupid for trying to be explicit in saying that this feature was not only for the root site. I’ve gotta be honest, that sucks, and it wasted me 4 hours. Clearly, it shouldn’t just be the presence of the attribute; by setting it to False I was saying specifically that the feature was not for root sites only. Someone was shoddy in their processing of the XML.

Error: "RootWebOnly='FALSE'" is True…

Deploy a SharePoint Master Page as a Feature

Andy Burns, , Leave a comment

SharePoint master pages are sort of designed to be created in SharePoint Designer. This isn’t much good, though, if you want to redeploy a master page to another or multiple systems. Also, a master page that has been created in SharePoint designer is “Customized” – that is, it is stored in the database rather than as a file on the file system. This makes it a bit slower.

What I wanted to be able to do for a customer was to create a SharePoint feature that would deploy all my physical files, and in such a way that they weren’t customised. Well, I think I’ve done that.

I pretty much followed the gist of this blog entry by Chris O’Brien (his blog is excellent and well worth a read).

You can also get a feel for it by examining the PublishingLayouts feature that comes standard in MOSS. That feature deploys all of the OOB master pages, etc..

In short, the approach is:

  • Create design in SharePoint Designer
  • Copy and paste master page code to a new aspx file in your feature, with the same name as the file in SharePoint Designer. (Do not just save the file in SharePoint Designer to the file system. It mucks up the links. Copy and Paste the code – just as Chris says to. Guess who forgot?)
  • Save all other relevant files to the your feature.
  • Create the Feature.xml file
  • Create the Elements manifest file. Note that the XML is case sensitive, and the case used in the blog entry above is wrong.
  • Make sure that the permissions on the feature folder are correct and inherited by child files and folders.
  • Run “stsadm -o installfeature -name featurename”
  • Activate feature at site or sitecollection level.

Attached is an example feature that installs a (rubbish) master page I’ve created called ‘Cairngorm’. To install it:

  • Unzip the archive
  • Copy the CairngormMaster folder to your Features folder in 12 Hive
  • Check its permissions
  • Run 
    stsadm -o installfeature -name CairngormMaster
  • Go to the Site Collection Features page, and activate it.

You should now find that you can select the ‘Cairngorm’ master page from the ‘Site Settings > Master Pages’ page. Select it for your master pages, and you should find your pages go a bit black and orange! You can get the dodgy design I came up with here, but please just use as an example – it looks bleedin’ awful.

Deploy a SharePoint Master Page as a Feature