How to find out what type of site a site is…

I’ve built a feature to active branding on a site including master page, navigation and themes, which I’ve been talking about a bit over the last few weeks. One issue, though is that meeting workspaces have a different master page to ‘normal’ master pages, so I need to set them to use a different ‘custom’ master page when the feature is activated. This means that my feature receiver has to ‘know’ if the site it’s being activated on is a Meeting Workspace, or some other site.

What defines the ‘type’ of a site is the template that was used in it’s creation. Continue reading “How to find out what type of site a site is…”

How to find out what type of site a site is…

Style the DatePicker using an Alternate CSS

A while back I posted about the how daft that the datepicker control isn’t styled by themes, and is in the _layouts directory, so you shouldn’t edit them.

Well, a while later Michelle posted with a good idea of how to brand them – use an alternate CSS URL. I must confess, this tip passed me by until my recent branding efforts, and I discovered her tip.

So why does this work? Well, if we crack open the file iframe.aspx (which I still think is a bloody stupid name. I mean, the defining feature is the DatePicker control, not the bloody iframe it uses) we can see the code:

There we go – code to insert the alternate CSS url (but not themes – obviously).

So, I gave this a go:

Tada! Styled date picker, nice one Michelle. However, she notes that it has to be applied to a publishing site, or to a publishing site and all sites below it. Site collections based around a team site would be tricky. Normally, this page is used to set the alternate CSS…

[image of site]

… and, well, Team sites don’t give you that page.

However, we can achieve this in code! All the admin page does is change the SPWeb.AlternateCssUrl property for a site or set of sites. We could have a feature receiver (a bit of code that is run when a feature is activated or deactivated) to do this:

public override void FeatureActivated( SPFeatureReceiverProperties properties ) {

SPWeb site = properties.Feature.Parent as SPWeb;

site.AlternateCssUrl = "[Your URL here]";

site.update();

}

More evidence that brands are best applied by feature receivers. Maybe I should make an example of this…

Style the DatePicker using an Alternate CSS

Programmatically apply a Default Theme in SharePoint

As I’ve mentioned before, I’ve written a brand that is a combination of Theme and Master Page, and is designed to be activated by a feature receiver. When the feature is deactivated, it should restore the previous Master Page and Theme – but it wasn’t doing this for the default theme. Weird.

Well, here’s another good tip from Madalina you have to apply a theme of none, not Default.

web.ApplyTheme("none");

That’s the second tip of hers I’ve found on Google and used in the last 2 weeks. Maybe I should start watching that blog. Anyway, I guess that ‘none’ makes sense when you look in 12/TEMPLATES/LAYOUTS/1033/SPTHEMES.xml – the default theme has a TemplateID of ‘none’.

‘Course my next problem for my feature receiver is that Meeting Workspaces use master pages (MWSDefault.master) that are significantly different to other pages – thanks guys, that’s helpful…

Programmatically apply a Default Theme in SharePoint

Updating the Navigation Settings in a Publishing Site

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!

Updating the Navigation Settings in a Publishing Site

Setting the Master Page of a Team Site with a Feature

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…

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

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