Posted on 14 November 2012 by Sam
For the past couple of years we have been making regular use of WordPress as a Content Management System. Several people have asked how we decided to use WordPress and what were the reasons for choosing it over the many other alternatives out there.
The real history is that there was no great plan at all. Before last summer Tim, James (no longer in the team) and myself were part of Children and Young People’s Services, predominantly the education side, where we dealt heavily with schools and their websites. Since about 2001 we had been helping design and build websites for schools as a way of meeting the eGov targets for all schools to have a basic web presence by 2003 (or something like that, it’s a long time ago!).
At that time schools were happy for us to undertake the maintenance of the sites on their behalf, they just email us changes and we sort it out. However, our little sideline was never properly scaled and we ended up with over 170 schools sending newsletters, policies, class work and more. Between three of us it was difficult to keep up at times and we found we were spending more and more of our time doing school work when we should and could have been doing work for DCC.
All the way along, some schools had been keen to manage their sites themselves and that desire to be self supportive was growing. We knew we had to look into a long term solution, one that would alleviate the pressure on us by reducing our support overhead and enable schools to do as much of their own site content editing as possible.
Our first effort at CMS was actually Macromedia Contribute. This was okay, but there were several bugs and flaws. The biggest problem, however, was the fact it required the purchase of software licences and had a steeper learning curve than most school staff were comfortable with.
In the summer of 2009, we started looking at the various open source CMS platforms that were now available. The main contenders, with school sites in mind, were Drupal, Joomla and WordPress. The main requirements we were looking for were:
1. Shallow learning curve for content editors – we didn’t want to replace our maintenance requirements with support calls on using the CMS. School staff had to be able to manage their website content simply and quickly in a system that was intuitive and simple to use.
2. Easy to customise – no two sites are identical. We needed the option of extending the basic platform with additional functionality and features at the click of a button. Many schools wanted, or had, many existing features on their sites and they wanted many more besides. This might be interactive calendars, twitter feeds, emergency news publishing, video and photo galleries and more.
3. Rapid template design – we didn’t want and couldn’t have a system that would take a long time for us to roll out a design. Our existing process was relatively rapid, plain HTML and CSS coding and using Dreamweaver’s simple template system to manage the overall look and feel. We needed something that would make it simple for us to use these existing skills and had a low learning curve for us in designing themes and templates.
Based on those three key requirements we started looking at the different platforms. The first one I looked at was Drupal. While it certainly appeared to be a very powerful tool, it was not at all intuitive. Looking at how to develop a customised theme, it was very complicated, at least from the perspective of our skills at that time.
Joomla was much the same and maybe worse. The interface was clunky and nothing made sense semantically. Templating looked equally as awkward as Drupal, maybe more so.
WordPress was the one that stood out in the “at first sight” stakes. As it started life as a blogging platform, and a relatively simple one at that, everything is labelled nicely. Posts, Pages, Media, Links, Settings… there’s no ambiguity or fancy terminology.
Creating a custom theme also proved surprisingly simple. A theme is made up of a set of default files (header.php, footer.php etc) and all you need to do is wrap your custom HTML into the appropriate parts of those files.
Admittedly, it is likely a similar exercise to Drupal, Joomla and others. However, there just seems to be a lot less complexity where the code is concerned. We were also able to find a building block theme called Starkers, which stripped everything back to bare bones and reset all paddings, margins etc. This allowed us to build a theme from the ground up with none of the conflicting CSS issues of editing the default themes.
Another major advantage with WordPress is the developer community. Not only was there a massive catalogue of plugins and functions freely available to make use of, but the online support community via the WordPress forums has proven itself incredibly useful.
In terms of managing content, for a school site it proved almost perfect. With the addition of a couple of key plugins we were able to make a very customised, but simple to manage website. We would never need more than 2 hours to show someone how to completely manage their own site and with a few reference guides we produced we rarely received calls asking for clarification on simple tasks.
When our CYPS service was merged with the Communications team we decided to end our service for school websites due to lack of resource to support them. However, the legacy of our work in WordPress development carried through to our new team and we have found WordPress to be a dependable and adaptable tool that not only gives us the power to create just about any site required, but one simple enough that anyone can manage themselves.
We have always said that we would decide on a platform based on the requirements of a job rather than trying to rig the platform to fit the task. We still hold to that, but the truth is that we’ve yet to receive a job that WordPress hasn’t been suitable for. Not to say it is perfect, it’s far from that. However, that accusation can be levelled at any platform. There is no one tool that will be all things to everybody and that’s as it should be. WordPress is simply a great tool for what we need and it can fit nicely beside other systems in a wider ecology of web applications. We are still learning how to wring more and more from WordPress with every project we undertake, but so far we’ve not hit a major snag that has no solution.