I’m updating this post for 2017, as things have changed considerably since I wrote it inititally.
There are lots of Content Management Systems out there. Drupal and WordPress are the two we work with most often. Why? Because they hit the two ends of the CMS spectrum, and have some broad overlap in the middle. Generally speaking, having worked with both WordPress and Drupal, WordPress is easier to work with. The setup is cleaner, the documentation is better, the experience of searching for and setting up plugins is less painful. However, that doesn’t mean that WordPress is automatically the right choice for every project.
When a new client comes to us with a CMS project, the first questions I ask are:
- How will your users interact with your content? i.e. will they be posting their own, or just consuming what you put up?
- Will you have users with a wide variety of roles/abilities on your site?
- Do you have the resources to train staff in a fairly complex piece of software?
- Do you have either internal infrastructure or a budget for regular third party maintenance and development?
With the answers to those questions, I can usually make a very solid recommendation for either WordPress or Drupal. Here’s how it breaks down:
Drupal thinks of user roles and permissions in a robust and deeply complex way right out of the box, which covers questions 4 & 5, where WordPress’s roles are not as granular. So if you have various user types that will have access to different types of content, or the ability to create different types of content, Drupal is probably a better choice than WordPress. To be clear: WordPress can do different user roles, but it still suffers a bit from its legacy as a blogging platform in terms of how robust it is.
Questions 3&4 are the ones that are the biggest variables. WordPress is exceptionally user friendly in the admin. It just feels nice to work in WordPress. Automattic (the company behind WordPress) has spent a LOT of time and effort on user experience, and it shows. This reflects the history of WordPress: it was built for users who were not tech savvy and just wanted a way to create a blog site. The Drupal community, on the other hand, has focused more on raw power. The capabilities of the platform surged ahead for developers who could handle the ultra techy environment, while little attention was paid to the user who just wanted to put up a simple website. Earlier versions of Drupal failed miserably at basic usability tests – new users were not able to accomplish the simplest tasks.
During the years from the emergence of these CMSes to the present, Drupal has made huge strides in improving the user experience for administrators. But it’s still not as good as WordPress. Not even close, really. On the flip side, WordPress has made big leaps forward in moving from being a blogging platform that people hacked into small websites to being a full fledged CMS – but it’s still not as powerful as Drupal. In a now famous series of tweets (and retweets) from early 2010, a Drupal user calls out WordPress 3 for being approximately where Drupal was 5 years prior in terms of custom content type management. A WordPress user retorts that hopefully (then soon to be released) Drupal 7 would be where WordPress was 5 years prior in terms of usability.
So the final questions deal with who will be actually be using the thing as a content management tool, and whether the client has the wherewithal to learn to use Drupal. To be clear: Drupal’s admin interface isn’t bad at all. It’s just not as nice as WordPress’s, and the underlying complexity of Drupal tends to show through a bit unless efforts are made to keep the moving parts hidden from users who don’t need to see them. As I mentioned earlier, there’s a broad overlap between WordPress’s high-end capabilities and Drupal’s low end. At the end of the day, they’re both just php, and can be hacked to do whatever you want them to do. They’ve both got huge pools of third party add ons (called Plug Ins in WordPress and Modules in Drupal) to extend their functionality, and they can both be themed (that is, have their look and feel altered) to suit any design concept. After a certain point, anything you do is going to be custom hacking. For WordPress, that point gets hit a lot sooner. So the question about training deals with where I draw the line between making something in WordPress to keep training on the eisier side for the client while simultaneously putting more work into customization; versus making our work a little easier by doing something in Drupal, knowing that the client will have a somewhat harder time with the admin.
What about Joomla, Expression Engine, “Flat” CMSes, or some other option?
Joomla exists in a kind of weird spot in the ecosystem, in my opinion. It’s a perfectly good, perfectly respectable CMS. It’s generally considered to sit a bit between Drupal and WordPress in terms of power. As a result of the increased power of WP, and the resulting overlap between WordPress and Drupal, there’s no site that would need to use Joomla. We began our foray into Open Source CMSes with Drupal, and started working with WordPress when WP3 was released. As a result, we’ve just never had much need to use it. If you look at CMS market share statistics, you’ll see that Joomla powers 9% of websites, while Drupal powers 6%. However, a closer view reveals that Drupal serves nearly 3x the pages that Joomla does… with only 2/3 the market share. A conclusion that can be drawn from this is that Drupal simply serves bigger sites than Joomla.
Expression Engine is what I think of as an “almost Open Source” CMS. The license to use it commercially costs something like $300. If you look at that number and think “gee, I don’t know if I can add that to the budget for my website,” then it’s definitely not for you anyway. It’s made to be really easy for designer/developer types who want flexibility in how the build things, but as a result will most likely require a significant amount of custom work to get it up and running. We work with one site in Expression Engine, and have used its underlying framework, called codeigniter, so we’re familiar with how it works. It’s another good tool, but it’s nowhere near as popular as the other three big CMS players. As a result, there are fewer developers who are familiar with it, making it a little harder to get inexpensive work done.
So-called “flat” CMSes generate static HTML files that are served by a bare bones web server. This results in increased security, speed and stability – fewer moving parts mean fewer possible points of failure. We’ve done some work with a Ruby on Rails system called Middleman, which was fine for us – we’re developers. It wouldn’t be a good setup for someone less savvy. There are others, but generally require a bit more knowledge than one of the more “standard” options.
So to broadly answer the question posed in the title of this post, which CMS should you use? If you’re creating a simple website with a few content types, and no need to register users as members of the site to add content of their own, you probably want WordPress. If you’re building a site with loads of user contributed content, complex interaction between different types of content, or a wide variety of user roles, you probably want a Drupal site. If it’s something in between… well, call us and we’ll talk.
Of course, as soon as I post this, I guarantee that a lot of people will want to weigh in with their own opinions, either confirming what I say or touting the virtue of their favorite CMS in whatever role I said it’s not great for. That’s fine. Everyone has opinions – this one is mine, and it’s based on many, many hours of work done with a variety of CMS platforms on sites large and small. I share it with our clients and potential clients to help them make an informed decision.