Page hit counter in MOSS

So, a customer of ours is upgrading to SharePoint 2007. One of the things they were looking for is a hit counter, so they can see the number of times a page was requested. This was easy for them to do in SharePoint 2003 – they’d just use FrontPage, and insert a Hit Counter web component. I’d never heard of such a thing build into 2007, but over morning coffee, I decided to give it a try. Much to my surprise, it works… …sort of.

There is a hit counter (albeit with an awful set of styles). It does work too:

Hit counter in SharePoint

That’s one of the better styles, believe it or not. So, what’s the problem with this?

Well, in normal pages, nothing. It counts; ’nuff said. However, publishing pages are a bit different. They store metadata in a ‘Page Content Type‘ and then use Page Layouts to render that data. What this means is that many things that appear to the user as separate pages actually use just one ASPX file for rendering their content – and this is where the hit counter doesn’t work. It counts the number of hits on the ASPX page – so instead of getting a number of hits on that page of content, you get the number of hits on content using that page layout. Which sucks a bit.

I’ll look into this a bit more soon, and see what I find. It can’t be that hard – apart from the whole ‘Page Layout’ thing, it’s not exactly rocket science.

Page hit counter in MOSS

Build page layouts without Breadcrumbs or a Title

Right, so SharePoint uses pages and page layouts – I won’t talk about the different types, but ask a couple of questions that’ve come up a few times.

  • If I create a new page layout in SharePoint, how do I get rid of the breadcrumbs?
  • How can I get breadcrumbs, but like the home page?

Here’s how… Continue reading “Build page layouts without Breadcrumbs or a Title”

Build page layouts without Breadcrumbs or a Title

WSS3 Pages – what's with all the sucky layouts?

Okay, so I’m not a huge fan of the out-of-box publishing layouts. I’ll be honest – I reckon that there should be about half of the layouts, and I don’t like the ‘Welcome Page’ as a description. ‘Generic Page’ perhaps?

Anyway, some of them have pretty cacky layouts, often with Summary Links built into the page (why? Can’t I just add a web part?) – but as a rule, they keep the left hand navigation for the site. This is good – users get confused when their navigation isn’t how they expect.

New WSS Pages, however, do not keep the left hand navigation.

This has led to more than one customer asking “where has my left hand nav gone?” Not an unreasonable question – after all, did someone think that users wouldn’t need standard navigation in team site pages? Don’t get me wrong, I like that you can get rid of the left navigation menu if you want – but I think this will be the exception, not the rule.

You can get the left navigation back using SharePoint Designer (and some cynics might suggest it’s a ploy to set SPD licenses, though I don’t think so). However, I shouldn’t have to! Can’t I have a couple of out-of-box layouts that are like, well, the one used in Default.aspx on my team sites? Is there a Codeplex project for such a thing, maybe?

Even better would be if Default.aspx existed inside a library like any newly created pages I build are. I don’t like that it is separate to the other pages in a WSS3 site.

WSS3 Pages – what's with all the sucky layouts?

What is MSOLayouts_MakeInvisibleIfEmpty()

I was looking through the code of SharePoint’s Blank Web Part page layout, and I kept finding elements called _invisibleIfEmpty. Now, I’d noticed that some page layouts, such as the Splash page layout had borders on their web part zones which were only shown if the zone contained a web part. I was interested in how this might work. People keep asking for web parts with borders, preferrably ones with rounded corners. Continue reading “What is MSOLayouts_MakeInvisibleIfEmpty()”

What is MSOLayouts_MakeInvisibleIfEmpty()

Putting a web part zone below the quick navigation menu

Previously, I’d been asked to put a web part zone below the quick nav for SharePoint pages. As it transpires, you can’t put web part zones on master pages – but there is no reason why you shouldn’t put one in an asp:Content control (indeed, that’s how you have to place them on pages). And I’d noticed this PlaceHolderLeftActions content placeholder. So I figured, why not put my web part zone into that?

To do this, I need to modify the page that I want this zone to appear for. It could be a Page Layout for publishing pages, or just a normal default.aspx on a team site. I’m using a blank site for this. I simply added a Content control, and dropped a web part zone into it:

<asp:Content ContentPlaceHolderId="PlaceHolderLeftActions" runat="server">
<WebPartPages:WebPartZone id="g_5AD648BF053647678E80875B48A60593" runat="server" title="Zone 1">

I saved the changes, and now when I go to edit that page I see:

Great! I can drop in web parts – here I’ve used a summary links web part:

But you may find the styling leaves something to be desired – but you can design that in!

Sure, you could find that you have to do this a lot of times if you want to do this for many pages, but if you’re using the publishing features, you only have to modify each Page Layout once, which is very handy.

Putting a web part zone below the quick navigation menu

How SharePoint Pages are associated with a Master page

So, yesterday’s discussion of the problems with master pages for Publishing and Meeting sites raised a bit of a question with my colleagues. If a site (SPWeb object in the code) has both MasterUrl and CustomMasterUrl properties, how does a page ‘know’ which one to use? Why do publishing pages use the value in CustomMasterUrl, and other pages use MasterUrl?

Well, to find the answer to that, you’ve got to look in the code of the .aspx content page. Here’s the top of one in SharePoint Designer:

Yup, there is a MasterPageFile as per standard ASP.NET. However, the value of this isn’t normal – it’s not the URL itself, but rather a token that gets replaced at runtime.

  • ~masterurl/default.master is resolved to the value of the MasterUrl property (i.e. the ‘System Master Page’ on a publishing site).
  • ~masterurl/custom.master is resolved to the value of the CustomMasterUrl property (i.e. the ‘Site Master Page’ on a publishing site).

If you look in, say, the default.aspx page on a team site, you’ll see that it uses ~masterurl/default.master.

If you look in, say, the default.aspx page on a meeting workspace, youll see that it uses ~masterurl/custom.master.

If you look in publishing pages, though, you have to look at the page layouts (which are the actual .aspx pages being used). These don’t have a have a MasterPageFile defined – what gives? Well, they inherit from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class, which sets the master page file internally during OnPreInit! You can see in Reflector that it’s using CustomMasterUrl though.

How SharePoint Pages are associated with a Master page

Pages in SharePoint IV – Publishing Pages

Publishing pages are specific to MOSS, as they require the publishing features! They’re not in WSS3! A good example of a publishing page is the default.aspx of a Collaboration site – that’s right, although the default page has the same name as for a team site, it is quite different:

Looks pretty much the same though, eh? That’s because it uses the same master page, but we’ll come to that in a bit.

These pages are are stored in a ‘Pages’ library (you can see this highlighted in the URL). They aren’t really like documents though; they’re much more like list items. Basically, these pages are collections of metadata columns. Different pages have different content types, such as the ‘Press Releases’ page type of the Publishing Portal site template. The other pages types that come out of the box are the ‘Article’ and ‘Welcome’ page types of a collaboration site.

These content types have different columns of data. For example, you might have a type of page for ‘Vacancies’, and that might have columns for position, salary, etc.. You might also have a type of page for ‘Products’ which might have columns for part number, cost, stock, etc..

Okay, so I’ve said that these pages are more like collections of metadata – how does this become a web page that you can see and read? Well, each page type has one or more page layouts. Lets have a look at one in SharePoint Designer:

These are kind of like master pages – they define the layout of our metadata columns in an aspx page. In the one shown above there are only 2 metadata columns, which I’ve highlighted – Page Image and Page Content.

Okay, but what about the master page stuff? Well, out page layout the content controls to go into our master page. Confused? It is confusing, so here is a diagram to show this:

Here you can see the page metadata being put into the page layout, which in turn puts content into the master page, which finally generates the output that gets sent to the user.

One advantage of this approach is that you can change between different page layouts for a given publishing page type – for example, you might have ‘Product page with image on left’ and ‘Product page with image on right’ layouts. Changing the page layout does not require editing any of the content.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Pages in SharePoint IV – Publishing Pages