When considering what Content Management System to deploy today, one question needs to be answered first.
Why not just use WordPress?
WordPress was created to be the software behind the popular blogging service¹, and only a few years ago would have been dismissed as little more than that. It was never conceived as a general-purpose content management system, but designed with the singular goal of getting a person’s words and pictures onto the Internet simply and quickly. The thing is though, that is the core functionality of content management. Do it particularly well, and you’re onto something.
Combine that solid core with the ability to add functionality and you’re really onto something. Though invented for blogging, conversion into a different sort of content management system – say a gallery, a forum, or an e-commerce store – is available through third-party plugins. There is a staggering ecosystem of (the last I checked) nearly 29,000 of these. Consequently WordPress has become the most popular CMS in the world. And not by a margin – almost by an order of magnitude. Sixty percent of all content-managed sites use WordPress, one in five out of the ten million most popular sites on the Web. I’ll give that a second to sink in.
But by the same token, using something so well-accepted feels almost like copping out. We’re students of this technology, we’re assumed to be on the cutting edge. What’s the point in being just part of the crowd? There are innumerable content management systems out there. Many use the same attractive PHP + MySQL open source formula. Others again are based on ASP, Java, Perl. Some are even designed specifically to create online galleries, which is certainly closer to what our client needs than a blog is. But while these are worth looking into, the requirements go well beyond just the presentation of images. There is a great deal of text that needs to be easily and well presented, and a dedicated gallery system might not envisage that. The client also needs to manage membership, promote upcoming events, and automatically archive past ones. We will need something extremely flexible, and WordPress scores highly there.
But it’s not alone. Joomla¹ is also designed to be extended – it seems particularly rich in image galleries – and unlike WordPress it was a general-purpose CMS right from the start. It will have to be on our shortlist, especially as the team has had some experience with it in the past. Perhaps the biggest mark against it is that, with only around 6,000 available extensions – about a fifth of what WordPress offers – it just seems less likely that the functionality to meet our client’s needs will be readily available.
Initially, my instinct was to use Drupal. Also designed from the start to be a universal content management system, this one has put even more emphasis on flexibility. So while with WordPress you can have a usable blog virtually the moment it’s installed, Drupal is at first confusing – all you have is a framework, with few features except basic database and user management. Useful functionality is added by downloading and installing “modules”, over 25,000 of which have been contributed by the community, very comparable to WordPress’s 29,000 plugins.
But while plugins and modules might sound like two ways of describing the same thing, there is an important conceptual difference. WordPress extensions are very much goal-orientated. If you wish for example to add gallery functionality to your site, you compare the galleries available and plug in the one that best suits your needs. Drupal modules are function-oriented. To add a gallery, you consider what additional functions it would actually require – image management, display, cataloguing and captioning for example, possibly also resizing and retouching – and add modules for those functions. You’ve got a huge smorgasbord of features to avail of, what you mix is up to you. Such a level of flexibility is both challenging and exciting. A much more precisely customised result should be possible with Drupal, and this is why it is considered by some to be the best CMS of all. But the learning curve is also infamously steep (see illustration). I have to admit that this is part of the attraction. I’ve built several sites based on WordPress and it presented little challenge; the Drupal one I started over two years ago is still far from finished. It definitely represents the greater learning exercise. But that is not the objective today. Even if the team could become sufficiently skilled with Drupal within the timescale, it seems likely that that time could be better spent.
Plus, with Drupal skills being relatively hard to come by, future site maintenance would inevitably be more difficult. Perhaps a clinching argument in favour of WordPress is that, as by far the most popular CMS in use today, future maintenance and improvement should not be a problem. Indeed as an open source tool with both a strong community and the backing of a commercial interest, WordPress would seem to combine the best of both worlds in terms of support.
I wish we could use all three just to see which came out best, but the postgrad workload is too heavy for that. We should be making our decision shortly. For now though, my money’s on WordPress as the one most likely to deliver the client’s requirements without excessive drama.
____________________________________________________________
