Selecting a Content Management System (CMS) — WordPress, Drupal, or something else?

First published on the miggle blog 27/3/17

Choosing the right CMS for your web applications can be a daunting task. Where do you start?

For a while at miggle, between 2011–2018 we were best known for the sites we built in the Drupal CMS. We also built sites in WordPress and MODX as well. For a period we used our own proprietary CMS, miggleCMS. And between 2008–2012 we were managing large amounts of content, via a team of editors, for AOL, Yahoo! and BSkyB. Adam, our Lead Product Manager had worked on integrating technology for national press titles online and in print. Emma, our Head of Ops, was Head of Ad Ops for a large publisher and I spent eight years across two portals. Alongside our team of Acquia Certified Developers we had a huge amount of experience in developing CMS and managing and monetising content especially for travel, media and not-for-profit organisations.

Too much information!

Google ‘Drupal versus WordPress [versus Joomla versus etc.]’ and you’ll get a whole heap of results: some good, some bad, some very definitely loaded and biased, based on the writer’s preference.

I’m going to try and give you a different viewpoint, based on the fact that here at miggle we used both Drupal and WordPress — as most often we find the choice is between these two. The opinion offered here isn’t based on a side-by-side evaluation, but on the recommendations we’d make, based on a number of criteria which we’ve described below.

Some considerations

The advice is based on these general considerations:

1. CMSs, like all tools, are only effective when placed in the hands of an expert.
2. CMSs (like all software) are only secure if you keep security updates applied. This is not a weakness, it’s common sense.
3. For all CMSs there will be a range of functionality covering what is available out of the box and what is available via extensions (i.e. plug ins and modules) as well as what will only be achievable by custom code.
4. Where you fall in this range depends on what trade offs you are prepared to make in terms of time, cost and details of functionality.
5. Custom functionality, by its nature, sits outside of the CMS and as such can’t be judged as part of the CMS. It is only as good as the developers who build it, and the standards and processes they apply towards writing, testing and documenting it.
6. Most popular CMSs deliver on the majority of features you are likely to need. It is unlikely you will be the first person who has ever requested your feature, and, if you are, no other CMS will be any better placed to fulfill that requirement.
7. CMS development aside, your product’s development is part of a lifecycle that requires planning, design, testing, deployment and measuring, most of which stand apart from the functionality of a CMS.

WordPress, Drupal or something else?

Economies of scale

According to Builtwith.com, 32% of the top million content managed sites are built with WordPress. The corresponding figure for Drupal is 3% . It’s logical to assume therefore that there are more WordPress developers than there are Drupal developers and that the cost of the former won’t be as high. However, as quantity is generally no assurance of quality, you may get what you pay for. The fact there are also more WordPress sites may mean that they are quicker and easier to build, and therefore cheaper. This is the view we took at miggle.

Therefore, to start off with, in making a choice we’d always ask you what your budget was. We’d divide that by our day rate and then take a view as to whether that number of days wasenough to do your project based on your requirements. Because we had more robust planning, design, testing, deployment and measuring processes around Drupal we made that calculation with Drupal first. If the budget was not enough, that would rule Drupal out. Given that budget often buys time, a short deadline in an environment where you do not want to make reductions in scope often rules out Drupal.

Why do we have better processes for Drupal?

Bluntly, we had better processes for Drupal because we felt Drupal was a more flexible, powerful CMS. We felt it suited longer term projects which require more iterative development over time, like a travel company which is adding booking functionality or a charity which wants to start collecting donations. WordPress we felt was better where the feature set remains relatively static, or where the site is expected to have a shorter shelf life.

One person or a team?

If you are fortunate enough to have a broad range of experts and specialists at your disposal then Drupal is a great solution for a team. Because WordPress is quicker and easier to get started with it’s a better solution for ‘jacks of all trades’. This is a common trait of product managers like myself. In general if you asked me what would I get my team to build a charity website in, I’d say Drupal. If you asked me to build it myself, I’d build it in WordPress.

There are companies who have the same processes around WordPress as we had for Drupal, who will see WordPress as a tool that is most effective in the hands of a team. It’s unlikely that they will see WordPress as a budget offering. Pragmatic are a probable example. (In the same way, you will also find individuals who can master all aspects of Drupal. Kevin Elliot of Very Useful Software is an example.) However, in our experience, Drupal was the more flexible and most team orientated; by dedicating most of our time to it and the processes around it we extended our ability to be more flexible with it.

If WordPress is quicker and easier and thus more cost effective, how can we make it cheaper still?

I think we make WordPress even more cost-effective by exploiting what it’s good at in terms of looking at effective, quick and easy ways of managing design, functionality, security, maintenance and hosting.

Design

From a design perspective there are a huge amount of production-ready, sector specific (i.e. travel, news) themes which can be used for the front end of the WordPress site. Any one of these can be made unique with a limited amount of designer or front end developer time, significantly cutting down on design and front-end coding costs.

Functionality

I’ve always seen Drupal modules as being independent building bricks, used in combination with each other and the rest of the Drupal ecosystem to create a piece of functionality.

WordPress’s broad equivalent are plug-ins, which, by comparison, in general provide a complete piece of functionality, like an image gallery. It’s not uncommon for there to be a huge number of plug-ins which do almost the same thing. Chances are one will give you pretty much what you want out the box, with the gap being filled by a tweak or a trade-off. Using plug-ins to get up and running with the most common CMS features is pretty quick and won’t require lots of site building or development time.

Maintenance: managing security updates

WordPress has a well established auto-update feature for applying updates when a security or minor release is available. For major releases, you have to initiate the update yourself. You also have to install plug-in and theme updates yourself, although there are ways by which you can automate the update of all plug-ins (via a code change), or selected plug-ins (via a plug-in!). Of course, depending on whatever else you have installed on your WordPress site there’s no guarantee that the updates won’t break it — so some level of regression testing is still a good idea. But that notwithstanding, on-going support costs, especially if the functionality rarely changes, should in theory be a lot lower. The one downside of auto-update is that it doesn’t, as yet, work with code that is version controlled (VC). There are also some security considerations, but these can be effectively mitigated.

There are ways in which Drupal can also auto-update, but it’s more complicated and costly to put in place and manage, because it is predicated on code being version controlled.

Maintenance: managing rolling out new functionality

The way in which new functionality can be rolled out depends in the first instance on whether the code is VC. A lack of VC means that any updates you make will require the site to go into maintenance mode for a period of time. Managing sites via VC requires certain processes to be in place, which are generally reflected in costs. However, if you don’t mind the odd period of your site being in maintenance mode (like at 2am for three hours on a Sunday) for updates those cost savings may be worth considering.

VC is the starting point in reaching a nirvana where updates can be rolled out without the need for a maintenance page. This is because it opens the door to code driven development (CDD), where changes to the structure of the data model are triggered by code, in an environment where code managed by multiple developers is continually merged together into iterative rebuilds of the site, a process known as continuous integration (CI).

It’s possible to manage VC/CDD/CI in WordPress, but we’d always argued that the processes to do so in Drupal were more wide-ranging and flexible. In any case we had processes and learning built around Drupal and neither saw the need, nor have the scale, to diversify.

Returning to our point on WordPress being easier for individuals, a system which is managed by one person has less need for VC because no one else touches the code, whereas a team of developers cannot work on a solution without significant pain without VC. In the right circumstances a lack of VC will save costs if you’re prepared to run or mitigated the associated risks we’ve described.

Hosting

If you’re not versioning your code then it’s less likely you need multiple environments (like a dev site and a staging site) and the build scripts to move code, databases and web site assets (images, documents) between those. Not only will that save on hosting costs, it’ll open you up to more hosting suppliers, thus providing more competitive pricing.

What other options do you have?

Your solution stack

It’s possible someone in your organisation will dictate that you need a Java solution, or something that runs on Microsoft server hardware (and that running Apache, MySQL and PHP on this isn’t an option). In which case, you might look at something like Umbraco.

Your internal resources

Similar to above, you may have a development team well versed in a particular technology, and if there is no appetite to cross train or up skill them (which is a service we offer) that will determine your choices also.

Software as a Service (SaaS)

Perhaps your site can be delivered by an online SaaS service like Wix, Squarespace, Shopify or ecwid. WordPress even offer a SaaS model via WordPress.com. With SaaS some level of vendor lock-in is inevitable, but for certain applications the trade-offs might be worthwhile in terms of cost.

Build it

You may decide to build something yourself from scratch, using a framework like Laravel for example. If there is a compelling reason for you to own your solution this might be an option. When it comes up, most times we are able to demonstrate this isn’t required, but of course there will always be exceptions.

So, if we’d come to miggle, it would have been WordPress surely?

Yes, your project was a WordPress project we’d have been interested in if:

1. The project scope was only achievable within the time and budget if we’d used WordPress, taking into account all of the cost saving factors and trade-offs mentioned in this post.
2. The site’s scope was unlikely to significantly increase over its lifetime.

If not we’d have said your project runs the risk of incurring technical debt, where some of the trade-offs we make, or tweaks we have to put in place, or plug-ins we rely on need re-evaluating within the life cycle of the site. The general premise of technical debt is that it always needs to be repaid. But if your site represents a short-term initiative, it may be gone before the debt is due. A good example of this might be a microsite around a particular campaign.

If there’s a risk that your site will incur technical debt that needs to be repaid, or that you want to use WordPress, but have a more robust set of processes around design, testing and deployment in particular, then we’d have likely maintained it was a Drupal project, because our use of best practices across the board there were more attuned — and because the framework is more flexible, so less technical debt is incurred, and less needs to be repaid.

Often, we came across a requirement for a collection of sites, with short life spans, like a series of advertiser funded microsites, with limited functionality, which are all in essence WordPress sites. Would we have built these all in WordPress? After all WordPress supports multi-site functionality. No, we wouldn’t. We’d have said that what you really want is a multi-site Drupal set up which delivers a family of sites for you from a single codebase, such as we did with Friday Ad’s Spidersnet, or with our NHS distribution. Why? Because changes we make to the core product can be easily and cost-effectively applied across all sites derived from it, maintaining consistency and cutting support costs.

Bottom line is, if we built in WordPress, we were quicker and cheaper, but we’d hit ceilings earlier. In making a recommendation to use either Drupal or WordPress you’d be trusting us to understand where that ceiling is — which is why planning and discovery are so important as part of the product development life cycle.

Where did we hit a ceiling with Drupal?

We never did, which is why it was our preferred solution.

Digital decisions are never a walk in the park, so let me help you find the right way through the technical landscape.