Drupal, WordPress And All The Rest

How To Choose a Web Platform

Note: This article was originally published on May 16 2013 on the SthlmConnection company blog. I think the general ideas are still valid, but the specific conclusions are probably out-of-date.

At SthlmConnection we help our clients evaluate their needs and work out a suitable plan for their online presence. After that, we investigate the best options for the technical implementation, that is, finding the most suitable tools for the job. As you may know, our favorite swiss army knife type of a tool is Drupal — a powerful open source content management framework that keeps serving us well after several years and numerous site launches in our portfolio.

At the same time, it’s important to keep an open mind and not choose a platform just because it’s the most familiar. It’s true what they say (although the expression may be a little overused): if all you have is a hammer, everything looks like a nail. This is why we start out new projects by defining goals and concepts, and only then proceed to technical considerations.

Sometimes clients do approach us with an existing idea of what CMS they want to use. Sometimes it’s Drupal (and we usually nod in agreement), but another common request is that we build the website in WordPress. In most of those cases, we’ll argue that whatever the client is looking for in WordPress, we can deliver with Drupal, with a number of additional benefits. But it would be foolish to maintain that there is never a good idea to use WordPress — it is after all a very popular platform with clear benefits.

That was all a very long way of introducing the topic of this post, which is: what are the differences between Drupal and WordPress, what are the benefits of each platform, and how do you know which one to choose for your project?

It’s also important to realize that Drupal and WordPress are just two options out of many, and there are definitely projects where there are better alternatives. Two solutions that we sometimes recommend for simpler projects are Jekyll and Tumblr (which might come as a surprise). For projects with very specific needs or more complex functionality, Ruby on Rails is often a good choice. But more on those later. (I’ll avoid mentioning any more tools to protect your sanity, but there are many many more, and some of you will probably miss your favorite tool among the ones I do mention!)

Drupal and WordPress — the basics

Drupal and WordPress share some basic characteristics: they are both popular, mature, open source content management products built with PHP. They both have large communities with strong support and lots of contributed add-on features. WordPress is the largest of the two by far, but Drupal is also one of the world’s most commonly used publishing platforms.

Drupal was born in 2001 as a message board system, while WordPress was first released in 2003 as a blogging tool. This says something about the differences between them: Drupal has its background in community building, while WordPress is optimized for publishing articles. Since then, both systems have widened their use cases radically. Especially Drupal has marketed itself as a general-purpose CMS for many years now.

Handling complexity

The most important aspect to consider when choosing a CMS is the scope and complexity of the project. The illustration above shows roughly what platforms I consider to be viable choices for different types of web projects, and I’ll use the remainder of this post to explain why. (Remember, these things are a matter of opinion. Also, this graph gives a simplified image of the actual situation. Projects can be complex on different levels, and a media website could very well be more complex than a community platform, for example.)

The example project types in the graph are:

  • Brochure site — static content, usually with a rich design.
  • Blog — a simple feed of posts.
  • News/media website — articles, sections, writers, blogs, etc.
  • Organization website — presentation pages, news, member pages, integration with external systems, multiple languages, etc.
  • Community platform — user generated content, user groups, individually customized content, social media integration, etc.
  • Web service — unique, tailor-made functionality, highly individualized content, email/sms/calendar/device integration, project specific APIs, service oriented architecture, multiple platforms like mobile apps, etc.

So why is Drupal positioned more to the right than WordPress in the graph? In general, Drupal is better than WordPress at handling complex projects that demand a high level of flexibility. There are a number of reasons for this, but the short version is that Drupal has a more generalized, abstract architecture where different features and content types all use the same general building blocks. This makes the possibilities of customizing, combining and integrating these pieces nearly endless.

WordPress does allow you to customize and build your own features on top of the core product, but the standard building blocks are fewer and less powerful. This means that different add-on features tend to not integrate as well with each other as they do in Drupal, unless they have been developed specifically to work together.

Some particular areas where Drupal provides richer functionality than WordPress are:

  • The powerful content modeling system
  • The flexible presentation features provided by the Views module
  • User related features (roles, permissions, groups)
  • Internationalization, or support for multiple languages.

Simpler projects like a brochure site or a blog are a very common use case for WordPress, and there’s no question that it is a good tool in this area. You can use Drupal for this as well, but it may be overkill depending on what you want to do — especially if you don’t already know Drupal.

The alternatives

Jekyll is a favorite of ours for simple projects (although Jekyll projects can be complex, too). It can often be considered as an alternative to WordPress. Jekyll is an open source static site generator written in Ruby. Being static means that the live site is always fast, secure, stable and low-maintenance. The drawback is that it doesn’t provide any online interface for content editors (but there are options here — see below). Also, there is no user log in, no commenting, or anything that would require a server side web application. However, you can do a lot more with client-side tools than you might think these days!

Tumblr is not actually a content management product that you can download and install yourself. It’s a free blogging service that provides very nice content features for pages, posts and media. It allows you to customize the front-end aspects of your blog any way you want, which means that as long as the content structure fits your needs, you can basically build any site that you want on the platform, especially since Tumblr allows you to use your own domain. The benefits are tempting: no installation, no development cost, no maintenance — and free hosting. What you give up is the ownership of your platform. Tumblr could in theory close down or change their policies overnight — but as long as you find them trustworthy enough (and many people do) and as long as the prospect of having to move to a different platform isn’t too off-putting, Tumblr can be a great option.

Ruby on Rails is different from WordPress and Drupal in that it is not a content management solution out of the box. Rails is an application framework that allows you to develop custom web applications using a powerful and streamlined programming API. You get a lot less out of the box, but it makes fewer assumptions about your application, and it helps you to quickly build out exactly the features you need. This makes it a good alternative if you don’t want to adapt your project to the standard behavior in any of the other solutions. It is also great as a backend for other applications, like mobile apps, social media apps, and third parties that need to integrate with your platform.

Budget and time to release

The flexibility and relative complexity of Drupal compared to WordPress means that it usually takes longer to get up and running. You can launch a WordPress site really quickly, especially if you use a readymade theme and don’t need to do any real customization. With Drupal, the out-of-the-box experience isn’t great. You’re usually required to install a number of add-on modules, even for simpler sites, and create your own theme for the project. (There are a number of Drupal distributions however, that come preconfigured for a particular use-case. Those can definitely give you a quicker start.) With frameworks like Ruby on Rails you’re usually looking at an even longer development time, since it’s more like starting with a blank canvas each time. This is not a flaw with Drupal or Ruby on Rails — it’s a natural consequence of the types of problems they’re meant to solve.

It’s important to realize that the rapidness of WordPress is only an advantage if it actually fits your needs. If you need to create a completely custom design — no problem. You can do all sorts of crazy, creative things in the front end with custom JavaScript. Adding additional backend features is also perfectly feasible, but as I described earlier — this is only true up to a certain point. As your application grows, it runs the risk of becoming increasingly hard to manage as you develop yourself away from the WordPress core. Again, the choice comes down to the project requirements — choosing a quick solution can prove expensive in the long run.

If you are on a tight budget, the first thing to do is always to limit the project scope and focus on the most important parts first. (Perhaps an active presence on social media is actually more important for your project than building a new website?) It’s much more important to get the basics right than trying to pack as many features as possible into the product at a limited budget. Apart from that, you should consider how you’d like your project to evolve in the future. If your needs are fairly simple, now and in the foreseeable future, then WordPress may very well be the right choice. You might also find that Tumblr works just as well, and that it can be a very efficient solution. With Jekyll you’re usually (not always) making more of a hand-crafted website, so it may not be the quickest in the beginning, but once it’s done the maintenance and hosting costs will be virtually zero.

Usability

WordPress often get a lot of praise for the ease of use for content creators. The conventional wisdom is that this is WordPress’ strength and Drupal’s weakness. Content creators usually like WordPress for its straightforward and familiar content editing interface, and because once you’ve learned it, you know how to manage just about any WordPress site. There are also mobile apps available for iOS and Android that allow editors to post content to a WordPress site on the go.

Drupal’s content editing experience that comes out of the box is decent, but not great. (Drupal 8 promises lots of improvements in this area.) One important difference compared to WordPress is that with Drupal the content editing experience depends very much of the structure of each individual website. Drupal makes fewer assumptions about what types of content you will want to use, so the content management interface is more generalized, and honestly a bit clunky sometimes. It is the site builder’s job to improve this situation, by installing editor plugins, creating customized admin pages that list different types of content, and so on. The good news is, this is actually fairly easy to do. (The bad news is that this is often down-prioritized in favor of the end-user facing parts.)

Tumblr has a great UI, as well as a very slick mobile app for posting content. Jekyll doesn’t have a UI at all — the basic idea is that you edit your content as flat text files (which is actually a very efficient UI in the end), but there is a project called Prose that provides a web interface for managing Jekyll content through Github. With Rails, the UI is very much up to the developer, but in practice this part is usually solved swiftly using packages like RailsAdmin that provide site admins with a basic, extendable content editing interface automatically.

The development process

As powerful as CMS’s are, building websites eventually comes down to programming: writing source code in different programming languages to define the project’s structure and functionality. Like software developers in general, web developers have great tools for structuring code, enabling collaboration, and dealing with projects that are changing continuously over longer periods of time. For example, version control systems like Git allow teams to compare differences between versions of files, work on the same files at the same time independently of each other, and push changes to different environments (like development, testing and production).

Jekyll and Ruby on Rails are both completely code-driven, which means that using these types of development tools comes very naturally. Both WordPress and Drupal however are site building tools that let you set up your site’s structure primarily through an admin interface — without writing any code. The site structure that you’re creating is stored in a database, together with all the content, user information and other data.

This means that they are in large parts missing out on the sustainable workflows commonly used in software development in general. Their database-driven approach generally works best for a single person building a new website from scratch. If you are a team building a site this way, everyone has to work on a central copy where all the final configuration will be made, and you have to make sure you’re not stepping on each other’s toes. The other problem comes when you already have a site running, and you need to make radical changes to it without taking it offline. This is difficult since such larger changes need to be developed and tested on a separate environment before attempting to apply them to the live site.

To remedy this situation, Drupal has clever ways of capturing this site configuration and automatically export it as code. (Drupal 8 has a whole core initiative dedicated to these issues.) Together with manually written code, it can then be put into version control to enable team collaboration and quick deployment of new features. In my mind, this is a huge benefit with Drupal over WordPress. In fact, developing large, complex websites without it would be really hard. (On the other hand, WordPress is less affected by database-centric approach in the first place, since it has fewer building blocks available to site-builders.)

This however doesn’t mean that you would necessarily call Drupal a developer-friendly platform. Ruby on Rails and similar systems are built with streamlined development as their primary goal, while Drupal, like most CMS’s, focuses primarily on providing a powerful web UI.

These are a kind of issues that are not visible to end users or site owners, but they do determine to what degree you’ll be able to continuously develop your website with a sustainable project structure and a good workflow.

Hosting and maintenance

Drupal and WordPress use the same type of server configuration — the very common LAMP stack. Drupal generally requires more server resources, but it really depends on the particular website. The supply of hosting companies that support this architecture is huge though, and it’s always possible to find affordable hosting.

Jekyll just needs a web server that can serve static files, which makes it very cheap and easy. Tumblr gives you free hosting. Ruby on Rails generally has somewhat higher demands on the hosting platform, but there are many hosting solutions available that specialize on Rails support.

Maintaining a website can involve a lot of different things, but the most common tasks are monitoring and optimizing performance, and doing security updates to the core system and add-on modules. The maintenance process is very similar with Drupal and WordPress. One difference is that WordPress is more exposed to security threats, so you need to be extra careful to keep the platform constantly up-to-date with the latest security updates. Ruby on Rails has similar maintenance challenges as Drupal and WordPress, even if it’s a very different platform.

Jekyll and Tumblr basically require zero maintenance, since the former is hosted as static files, and the latter is handled by the Tumblr service.

Conclusion

Choosing the right platform for a web project comes down to a number of considerations that I have tried to outline in this post:

  • Project requirements and complexity
  • Budget and time to release
  • Development process and project sustainability
  • Hosting and maintenance

Apart from that, you need to consider the skills and knowledge that you and your team already have. Learning new platforms is fun and important, but if there are budget and/or time constraints, you will probably be more efficient with a tool that you already know, provided that it actually meets demands of the project.

I hope you have found this comparison useful, and that it will help you choose the right platform for your next web project!

Further reading

Big thanks to Henrik Sjökvist, Per Sandström and Jacob Brydolf for checking the sanity of this post!

Originally published at www.sthlmconnection.com.