I was reading Andrew Connell’s book ‘SharePoint 2007 Web Content Management‘ and it made something crystallize for me. I’ve been pondering this for about 8 months or so, but I believe that several of our customers are using the Publishing features of MOSS incorrectly, and that simply basing sites on out-of-box Collaboration and Publishing site templates is a mistake.

(Well, at least without additional planning)

The Publishing features of MOSS give you a new type of page (a Publishing Page), as opposed to the Site Pages you get in a team site. Whereas a ‘Site Page’ is a full .aspx page in itself, a Publishing Page is really a content type and one or more associated Page Layouts. In other words, a Publishing page is a set of metadata that we want to display on the page, and a Page Layout then takes that data and puts in into a page

What this means is that, as with any other content type, you have to plan it before you start putting content in. This planning is important – the Page Content Type defines what data you’re capturing from authors, and if you capture the wrong data then it’s a manual process to sort it out. Worse, if you have different types of page – such as ‘News Articles’ and ‘Parts Catalogue Pages’ and ‘Job Adverts’ – and you put them all in as the one content type, well, how do you separate them? You can’t! What if I want to add a ‘Parts number ‘ field to my ‘Parts Catalogue Pages’ but not my ‘Job Adverts’ pages? You can’t! As far as SharePoint is concerned, they’re the same damn thing!

Unfortunately, this planning doesn’t always happen.

The problem that Andrew Connell’s book highlighted is that there is no such thing as a ‘Blank Publishing Site’ in the out of the box site templates. Site Templates such as the Collaboration Site Template come with ‘Article Page’ and ‘Welcome Page’ content types, with a number of page layouts (which are slightly spuriously designed, in my opinion). I think these are intended as examples.

Unfortunately, I don’t think that this is often recognised. Some customers go ahead and just use these content types and page layouts to enter content without planning – and only later realise that they needed to capture more details, or to separate different type of page, or to customise navigation for certain types of page.

Once you’ve realised that the Pages need to be separated into different content types there is little that can be done. I expect that the only solution would be manual correction. When you’ve got less than 20 pages this is onerous – more than a hundred is just outright painful.

Further, the page layouts themselves also impact the branding of a system; navigation, look and feel, even the styles used on the page. Hence, that needs planned too.

The thing that made me realise this problem was that in his book Andrew Connell was describing building a ‘Minimal Publishing Site’ – the basic bare-bones site, without the dozens of branding files, unnecessary page content types and layouts and features. I’m going to suggest that actually a Publishing Site Template that is too basic to use is actually better. By being too basic to use you force the consideration and analysis of Page content types, page layouts, navigation, and features.

The Technet ‘Plan Web Pages‘ document is pretty good, and goes into planning how you’ll guide (i.e. restrict) your authors. It’s also worth considering planning your authoring. There are many ways of putting content into pages.

So, what do I want you to take away from this? Well:

• Any site using the Collaboration Portal or Publishing Site templates needs to have planning given to the types of pages, and how they should look. For some systems we may choose to build our own publishing site definitions based on some ‘minimal publishing configuration’.
• Treat the Collaboration Portal and Publishing Site templates as examples, not solutions.
• That when using the Publishing features, treat MOSS not as a solution, but as a platform to build upon – building page content types, layouts, custom navigation and other controls. The good news is, that’s fairly easy.
• Going ahead and shoving content into SharePoint using the default content types without that planning is pretty disastrous – that always causes difficulties.