Category: drupal

When it comes to Content Management Systems (CMS’s), i’ve been “round the block a few times” so to speak, having spent the last ten years mostly working on CMS driven sites – starting with bespoke classic asp/ MS Access (shudder) back in 1999, before moving onto bespoke php/mysql systems, wordpress, drupal, zope/plone and dabbling in countless others. My conclusion: there is no holy grail, because the people developing and maintaining the code and content vary, and there are other important factors. Therefore I always take time to decide on the best approach for each project.
It is rare that I get a “greenfield” project where I am free to start from scratch. Without getting right down to weighing up the pros and cons of individual systems, here are some of the factors that help me (and my clients) make a decision:-

• Will I be starting from scratch or building on something else?
• Am I working alone, or with one or more other developers?
• Does the client have a preferred technology i.e. if they already have an intranet written in a particular technology, it makes sense to use the same for their website. (Unless of course they hate their other systems – it might be a good bargaining point to go a different direction altogether!)
• What’s the content like? – is there a large amount of text content, categories and pages or is it “snippets” of text that need to be editable, amongst otherwise highly graphical content?

Commercial Content Management Systems
I’m not going to talk about the “big” commercial CMS’s – the only people they are useful to are the people who’s job it is to go and buy a CMS license, companies who own or sell the software and companies who have made the investment to become specialists in such systems. That counts me out, and as i’ve never heard a developer, designer or content manager singing the praises of such a system (entirely the opposite), i’m going to presume they are all overpriced rubbish, and talk about what I know! I know that sounds flippant, but I refuse to believe that any of the vendors of the expensive, closed commercial systems have solved problems that a community of thousands of people working on competing open source systems haven’t. Also money saved on an expensive license can be spent on support, maintenance and customisation of a system with no license costs. Which brings me onto…

Off-the-Shelf open source CMS’s
One obvious route is to use one of the mature, all singing and dancing systems like Plone (zope/python) or Drupal (php/mysql). They are easy to install and have a comprehensive feature list, but usually one other thing in common – voodoo. By voodoo I mean a whole load of essential code deep down in the architecture that your average web developer (counting myself here) isn’t supposed to touch, and can spend hours/ days working out how to hook into it to make seemingly simple changes. For someone who becomes an expert in the system, they have full access to the code, so become familiar with the hooks and this isn’t a problem. For the charity/ company/ organisation where the development budget has run dry, it can be tricky finding anyone (available) who can work on it. If the content maintainer likes the admin interface these can work out really well, if they don’t it can be a ton of reverse engineering to make it “work” for the content manager.

Bespoke CMS’s
On the other extreme you have a bespoke CMS written from scratch giving the developer fine grained control over everything they need to do, and easily picked up by another developer, provided that it is sensibly written. However, as developers usually have their own way of doing things, it may take another developer time to learn how the system works before they can make changes, or they may want to re-write it altogether! The downside of any bespoke system is that it can take months to build features that you get for free in an off the shelf system. I often build a bespoke CMS where I need to bolt new functionality onto an existing system, where there isn’t enough budget to start from scratch.

Bespoke CMS built on a framework
In between are bespoke systems built on a framework (such as Cake PHP, Ruby on Rails, Django), so much of the repetitive coding work (such as user management and admin forms) is handled for you, but it’s still a bespoke system. The downside of these is that you need a developer who already knows, or is willing to take the time to learn the framework. The upside is that new functionality can be added quickly and in a consistent manner by someone familiar with the framework.

“In-House” CMS
By which I mean a bespoke CMS which isn’t written from scratch each time, but a mature “tried and tested” bespoke CMS built and maintained by an agency or developer, then reusued or repurposed for each new project. The advantage of this is that the developer/ agency have a high level of familiarity with the system, so are able to make fine-grained changes as required, that they may not be able to make with other systems. The disadvantage is that these can be the trickiest systems to be picked up by another agency or developer, and their may be IP issues (see below)

Intellectual Property / licensing
I’ve already said that i’m not going to talk about the commercial CMS’s, but one consideration when choosing which way to go, particularly with a bespoke CMS, is what happens if you were to move to another developer or agency? Will the source code and database files for your CMS be handed over along with the website or are you going to have to license it /buy it/ start again? Also what would happen if you wanted to sell the website and CMS on at a later date?

Standalone vs Retrofitting
This refers to the last of my bullet points above – not all websites are the same. Some (like news or university websites) are text-content heavy, with hundreds or maybe thousands of pages and categories, and some websites have highly designed (as in graphic design) content.

In the latter scenario it is often better to build the site as static HTML first and retrofit a simple CMS later. The bulk of the work in building such a site will be in getting it looking and behaving correctly, and their may need to be lots of fine tuning to the layout, which is easier if you aren’t reverse engineering a theming system. Moreover, the text content may be confined to small snippets of text, or a simple news blog, which can easily be plumbed in later.

The former scenario would suit an off-the-shelf system that works standalone – i.e. one that allows content editors to start populating content before the templates are finished, which are then applied as a skin/theme later – it may even be the case that the site can’t really be designed properly until the architecture and content are in place.