The Drupal/WordPress choice: A guide for individuals, small organizations and the Internet

Note: This is a much longer post than I intended. Therefore, I could not face rereading all of it and fixing it for clarity and grammar. Let me know if something is too opaque. Also, not everything that could be linked is linked. Let your fingers do the Googling.

All of the things in this post apply as of August 2012. Drupal won’t have a major new release at least until August 2013 but WordPress is planning 3 releases before the end of 2013. Drupal 8 will bring a completely new paradigm but WordPress releases are much smaller so we can only expect relatively modest changes. Given that it will take at least another 6-12 months for Drupal 8 to have all the necessary modules available to make it fully usable, I predict that much of this guide will be relevant at least through mid 2014.

The Drupal / WordPress choice

The web is liberally littered with “What is better WordPress or Drupal” debates (sometimes with Joomla thrown in for good measure). As a long time user of both, I don’t think this is a useful question. But neither is the common answer that they both serve a different purpose. That is true up to a point but I think the real question is not “what” but rather “when”. When it comes down to it, there is nothing that WordPress can do that you could not do in Drupal. But there are many features of Drupal that simply cannot be replicated in WordPress. (Here I’m talking with available modules without significant code.)

There are many ways to compare the two and a web search will reveal many such comparisons. Here I focus on the sort of considerations an individual starting a blog or a small personal site or small institution (such as a school, interest group or a no-budget charity) needing to establish a web presence should take into account.

What can only be done in Drupal

In my mind, Drupal equals Views. It is a module people have to install separately (although that should change in the next version) but it is absolutely amazing. It lets you create searchable and sortable listings of almost anything in almost any way. There’s nothing out there that gives you the same power through an interface that anyone can learn (I know because I taught it to several web development novices).

Views makes it possible to leverage Content Types (aka CCK) which is basically a way of creating complex forms for creating content. WordPress has recently introduced this functionality but without a Views equivalent, I have yet to find much use for it (although I’m sure others have).

This means you can build a listing of videos, books or a personal ad submission system in minutes without writing a line of code.

If you add the excellent Rules and Flag modules, you can create complex approval workflows for the submission and moderation of content that can make your site powerful and interactive on a level far above the investment in development.

There is a WordPress module called the Query Wrangler that has some of the functionality of Views but is nowhere near powerful enough. I couldn’t find anything that would make up for Rules and Flag.

There are other things where Drupal is more flexible and/or powerful like theming, user permissions but I think WordPress has exactly the amount of power it needs for it does here.

Drupal is also much more flexible in assigning URLs to content which can be extended by the Pathauto module to give you real power, particularly when combined with the amazing Token module (now partly in Drupal core). WordPress gives you some customization of URLs but is much more limited here. In Drupal, you can have defaults that you can override for any individual path but in WordPress you can only modify the last segment of the URL.

I also absolutely love the Biblio module for managing references (e.g. http://dominiklukes.net/bilbiography) but WordPress does have equivalents albeit with less power.

Obviously, Drupal is also a more powerful development framework so it can be used to build websites of complexity that is far beyond anything WordPress can do – from complex communities to vast ecommerce. But this is a post for people making simpler decisions than that. If you’re a corporation, you should really be talking about how to deploy Drupal, not if (outside some limited areas).

Where WordPress shines

Ok, so to repeat, in terms of functionality, there’s nothing that WordPress can do that Drupal can’t do (with additional modules). But there are some areas where it is simply far easier to use.

Posts and pages

I’m going to start with somethingt that is actually a weakness or a disadvantage for WordPress as a platform but a boon for usability. It stems from the evolution of WordPress from a blog to a light-weight CMS.

When you create a WordPress site you get a dashboard with 2 areas: Posts and Pages. So even if you don’t know much about how websites work, you know enough to simply post an update: “Hi, this is my new blog.” and a page that says “About me”. And it’s only a short step to figure out how to create additional pages and organize them in hierarchies if you’re more after a site than a blog.

Now, this is not the best way to do it. A far better way is what Drupal does, which is to have just one type of thing (called node) which you can designate to be anything you want. But this means that Drupal is much more conceptually difficult (I know because I’ve had to teach it to lots of people). I often have people new to a Drupal install ask, but when I post a new Page, where does it go? There’s never such confusion in WordPress. It’s completely intuitive but that intuitiveness comes at the cost of flexibility.

In a way, this could be a good litmus test. If you’re beginning to feel that the page/post distinction is too limiting, it’s time for Drupal. (BTW: If you find yourself using only pages, you might consider Joomla but it’s been a while since I made a test Joomla site and the one time I did for real, I moved it to Drupal within a month and never looked back.)

Comment management

Let’s be honest! Comments management in Drupal sucks. I’ve had a brief exchange with Dries (Drupal founder) on a thread on Drupal.org but I was not able to convince him. But I have two sites with lots of comments to moderate. One in Drupal and one in WordPress. I fell a bit behind in moderation and the Drupal one got so bad, I ended up just giving up and turning off comments. The WordPress one was easy to keep track of. It’s not the actual features for moderation or spam control, its interface.

WordPress lets you see enough of the comment to make a judgement whether to keep it, Drupal only shows you the title which in the days of creative spam is simply not enough. WordPress gives you edit, spam, etc. links in individual comments with immediate results. I love the quick edit and history features. Simple, elegent, powerful. Deleting a comment in Drupal can be a three-click process. I don’t get it.

Posting content

Here’s another area where WordPress is just much easier out of the box. Drupal can replicate most of the functionality but you have to work for it.

By default, Drupal just gives you 2 buttons at the bottom of the content creation page: Save and Preview. You can do a draft but clearing the “Published” option but somebody has to tell you and you have to remember.

WordPress, on the other hand, let’s you save draft, preview, schedule post (something Drupal needs a separate module for), password protect (something really complicated to set up in Drupal) and publish. All easy and intuitive.

There is also autosave which has saved my bacon many a time. With Drupal you have to rely on the good graces of browser extensions such as Lazarus.

Having a Trash function before you get to delete, is also very useful. It’s slightly redundant because unpublish does a similar thing, but redundancy is often a good thing in user interfaces. I complained about Drupal’s tendency to rely on minimalist logic before.

You can assign categories but unlike in Drupal, you can actually create new ones directly in the post. Now, the Drupal taxonomy system is much more powerful but it is conceptually very difficult (the study of categorization is my area of academic expertise and it was tough for me to figure out).

Out of the box rich-text editing

Oh, my God! The endless debates in the Drupal community whether it should ship with a built-in rich-text (WYSIWYG) editor. It doesn’t. There are ample modules that will let you choose and install pretty much any WYSIWIG editor in the world. This is good. But in my experience, the WordPress default rich text editor is superb. It has an amazing full screen feature (better than anything else I know), it has keyboard shortcuts, easy linking to other posts on your site, limited and full mode, help…

Drupal can do all or most of that but it needs complicated set ups and configuration. Sure, that can be useful when you have complex needs but I have never once found anything I needed missing from the WordPress rich text editor.

Multiuser vs Multisite

The ability to run multiple sites from one install has always been a huge attraction of Drupal. And with modules like Aegir and other magic, you can deploy sophisticated new sites in seconds (just see http://drupalgardens.com or http://www.buzzr.com). I think all universities and funding bodies that they should just offer this functionality to their departments or projects, so that they can deploy a powerful site very quickly for their many needs (from collaborative projects to conference sites to full fledged department sites and subsites).

But WordPress MU (Multiuser) makes this so much simpler. So if you’re a school or even a school district, you can be up and running with a system that replicates WordPress.com in a half a day of work (or if you’re somebody providing services to schools, as I know some people do). I run about 15 WordPress blogs (for myself and people I know) and most of them are on the same multiuser system. You just pretty much install it, configure and few things and it runs.

I also have a Drupal multisite set up (several in fact) but all new sites have to be rolled out manually. To replicate DrupalGardens is simply too much server work for me (and I am happy to get into Apache config files with Vim – for those who know what that means).

There are two WordPress sites that I host for other people as standalone set ups. But those are set up that way because I expect them to move the whole thing to a different server one day. Which is one downside of WordPress. It’s quite complicated to extricate one site out fo the Multisite set up (easier to just export and import).

The key thing to remember is that the WordPress and Drupal multisite features have different purposes. The main purpose of WordPress Multiuser is to establish a network of interconnected blogs with features like following and reblogging. I just happen to use it to simplify maintenance of multiple sites. Drupal multisite, on the other hand, is to make maintenance of many sites simple. There is no interconnectedness built in – although DrupalGardens add some of it in.

Upgrades and Maintenance

The main reason (apart from ease of posting simple stuff and managing comments) I keep most of my small sites and blogs in WordPress, is the ease of maintenance that we got with WordPress 3.0. It’s even easier to upgrade a plugin or a theme than it is to install software on your computer. You just push a button and it downloads the right version and installs it. The same goes for upgrading WordPress. Just a click of a button.

Now, purists will talk about the dangers of this and I agree. You should always test your upgrades. But WordPress is simple enough that an upgrade rarely breaks anything significant. I’ve been doing for almost two years and it always worked like a charm (a few glitches on the complex sites but never anything catastrophic). The WordPress plugin repository helps by listing plugin compatibility as well as what versions it has been tested on.  The Drupal module repository has lots of helpful features but this is one thing it does not do.

Drupal on the other hand, takes a lot of time to maintain. Since Drupal 7, you can install modules more easily simply by uploading a the module file or pointing to a URL where it is hosted. But if you’re still on Drupal 6, to install or update a module, you have to download it to your computer, unzip it, FTP it, and install it. (Or if you can use SSH and the command line, you can simplify it by downloading direct to the server.) To apply a security fix to Drupal takes about the same amount of work (but you have to be careful not to overwrite your settings). Like WordPress, the Drupal checks in with the module repository and will let you know if there’s a new version of a module and let you upgrade it.

But if you want to upgrade to a new version of Drupal, prepare yourself for a world of hurt. So much so that it deserves its own section below.

Before, I get stoned (criticised not take drugs) I need to mention Drush. It is a command line interface for the server geeks which actually makes managing a Drupal install a doddle. But you know that Drush exists, let alone how to use it, you’re probably not reading this post (although, I think you should to fix the Drupal comment management interface).

When Drupal and when WordPress

My recommendation is simple:

If you’re an individual or a small organization without any web development budget or in house technical skills, start with WordPress. It’s easy and most importantly simple to move to Drupal later. Going in the opposite direction is much more difficult (see below).

For instance, let’s say you’re starting a project, need a quick and dirty but professional web presence or want to build a blog for a course. Go to WordPress.com, play around and make a site. If you outgrow it, move to Drupal.

In most cases, if you’re an organization with an annual web development and maintenance budget (in the thousands rather than hundreds), you should go straight to Drupal.

You should also go to Drupal if you need complex permissions for site areas and approval workflows. But if you do, why are you reading this?

Also, any time you need a site with lots of pieces of information in it (rather than just individual pages) that needs to be displayed in many different ways, Drupal is a no brainer.

On the other hand, I would go as far as to say that if you’re planning to blog a lot (particularly if your organization wants to keep more than one blog), you may want to consider running WordPress (Multiuser) alongside Drupal.

How to start with WordPress or Drupal: Some free options

To that the answer is simple. WordPress has WordPress.com and Drupal has DrupalGardens.com. They will let you build a site and will host it for you for free and sell you upgrades for functionality like your own domain or more space.

There are alternatives to both services (e.g. Edublogs for WordPress and Buzzr for Drupal).

Neither site will let you add modules they don’t support. So if you have such a need, both WordPress.com and DrupalGardens.com allow you to export the site but they have different strengths derrived from their foundations.

WordPress.com only exports your data which you can then import to your own installation of WordPress or to a completely different system that supports WordPress imports. This could be Blogger or Squarespace, and, of course, Drupal.

DrupalGardens.com on the other hand, lets you export the whole site. You get all the modules (except the nice theming one) and the database. You can then move all the files to your own server and voila, there’s your site. I’ve even used DrupalGardens as a quick (and free) way to get a Drupal site for my server.

But DrupalGardens suffers from a problem with Drupal which is that you pretty much can’t export just the data and move it somewhere else. This is a consequence of the power of Drupal which requires a much more complex architechture. On the one hand, this means you can have a site that is completely customized to your needs but it also means that there’s no easy way to move it to another CMS.

Moving to and from Drupal

To be fair, in the Drupal space, there are some very powerful data handling tools that let you do complex imports and some export modules that let you get parts of your data out. But the more customization you have done to your site (which is why you went with Drupal in the first place), the more work it will be to move it somewhere else. In this Drupal is no different from other CMSs that are more than just a blog plus some pages.

But if you find out that Drupal was just too much for your needs (as I am now finding out with one of my sites), it will be more difficult to move to WordPress than the other way around.

The Drupal upgrade caveat

Let’s face it. Upgrading a Drupal site to a new version often means building a new site. On a simple site, it is straightforward enough. But I’d say, if your site is simple enough that it can be upgraded to a new version of Drupal without some pain, you should probably be using WordPress.

Here’s a little factoid that illustrates the difference nicely. A typical WordPress site will only create 11 database tables and pretty much stick to that even if you install new modules. A Drupal site will start with 60 and will easily end up with 150 as you add modules. So you can see the complexity of the upgrade will be much greater.

There are several things people considering Drupal should know.

1. Drupal has a no backward compatibility policy. If the developers think a new feature is worth it, they will build it, and
2. This means that with every new version of Drupal, EVERY SINGLE (and yes, here I’m shouting) module needs to be upgraded. Very rarely, this is a matter of find and replace (even I was able to upgrade one trivial module this way) but most of the time it involved refactoring.
3. This means that lots of useful modules take a long time to get proper upgrades. Or never get upgraded at all. Drupal 7 has been out for 2 years now but there are some big modules that have not been updated properly (Quiz and Notifications are 2 I had to deal with recently). And Drupal is almost nothing with without Views and that took about 6 months to be ready.
4. This means that if you rely on some nifty module (and don’t have the resources to get it upgraded), you either have to do without or not to upgrade. There’s a busy site I built only 3 years ago that is still on Drupal 5 because some key modules have never been upgraded or lost some funcitonality in the process.
5. Very often there is no good upgrade path between Drupal versions for data from non-core modules. To move from Drupal 5 to Drupal 6, you had to recreate all your Views from scratch. Thus I still have a few Drupal 5 sites that I simply did not bother updating.
6. The Drupal team only provides security updates for 2 versions of Drupal at any one time. The current version and the version before. My pleas to to change this to members of the Drupal security team fell on deaf ears. There should at least be a grace period of 6 months between versions, to give people to upgrade. But I think the next version of Drupal should be a long-term support version.

One of the consequences of this is that Drupal is now developing relatively slowly as opposed to WordPress which is adding new nifty features every 6 months or so. There are discussions of how to change this in the Drupal community. But nothing is going to change until Drupal 8 is out which could easily be another 1-2 years.

Things worth a mention

There are a few things that just didn’t fit into this outline that I’d like to put on the radar. Also, I listed some other Drupal usability shortcomings in a previous post.

Extending Drupal and WordPress core functionality

• There are lots of modules available for both Drupal and WordPress (called plugins on WordPress) to extend the functionality of the system. But as I indicated, Drupal will be much less useful unless you install at least the Views module. WordPress, on the other hand, gives you a full featured blog without having to do almost any configuration and no additional modules. You will need at least some non-core modules to get the same with Drupal.
• Almost all Drupal modules are free but many WordPress plugins are commercial (although there are free alternatives for most of them). This could be both good and bad and there are discussions in both communities on how to deal with it.
• Drupal distributions are a powerful ways of packaging Drupal for particular purposes (their main weakness is that they are not easily combined with each other). They are a collection of pre-configured modules and custom features that can be installed out of the box. There are distributions for conferences, newspapers, communities, hotels, academic sites, government sites, ecommerce, etc.
• Both systems can be used to create communities. Drupal has a module called Organic Groups plus there’s a community distribution maintained by Acquia called Drupal Commons. WordPress has a module called BuddyPress which can do quite a bit out of the box, too.
• Both Drupal and WordPress integrate with external services or plug in to separate systems. CiviCRM is one example that has recently included WordPress alongside Drupal and Joomla. But I’d say there are more such integrations with WordPress that are offered by service companies out of the box (e.g. for ticketing systems, podcasting platforms, etc.).
• When it comes to the number of modules/plugins, the platforms are roughly equal. The total number of modules listed on Wordpres.org is about 20,000 and the total number of modules listed on Drupal.org is about 10,000. But that is across all versions. Drupal only has about 6,700 modules for version 6 and 4,500 modules for version 7. There is functionality overlap in both repositories but it seems to be much greater in WordPress. When you search, for instance, for Calendar in the WordPress plugin repository, you find about 20 modules that more or less replicate each other’s functionality. In Drupal, you find 2 competing modules and a bunch of complementary modules. So the process of testing is much shorter.
• There are some Drupal modules that make it worth using it alone. For me, the two big ones (in addition to Views, Rules and Flag) are Webform (for creating surveys), Biblio (for managing references), Event/Calendar (for you guessed it). They have WordPress equivalents but not as powerful. There may also be WordPress modules that may swing your decision in that direction but I have not come across any yet.
• WordPress has a really useful and fully functional mobile phone app that you can use to properly manage the whole site. Drupal (due to its backend complexity) has no such thing. It’s also much easier to blog in WordPress using desktop software tools. Drupal is much more limited here.

Drupal and WordPress accessibility and use in other languages

• Both WordPress and Drupal are very much accessible on the front end but less accessible on the backend. There was a big push to improve Drupal backend accessibility that resulted in much better experience for screen reader users. The WordPress backend is mostly accessible but has some silly problems that make certain bits inaccessible to screen reader users.
• Both WordPress and Drupal are available in multiple languages. So if you want a site that’s all in Czech or Swahili, you don’t have a problem on either platform. But Drupal is much more powerful when it comes to single sites that need to be multilingual. (It has to do with Drupal’s amazing flexibility to modify the interface.) However, there are plugins that let you have a multilngual site in WordPress, as well.

Drupal and WordPress on large sites

• Both WordPress and Drupal will run into scalability issues in different situations. Ultimately, Drupal has more options to be scaled up (it is used for the Grammies during their live broadcast). But WordPress might be easier to scale up for someone with simple hosting.
• There are high profile sites build on both platforms. But Drupal has most of the big names from WhiteHouse.gov to the Grammies. TechCrunch and BoingBoing are examples of large sites that run on WordPress. But these are all news-like, bloggy sites. I only know of one large institutional site running on WordPress which is University of Mary Washinton although many large institutions use WordPress for their blogs (sometimes alongside Drupal for community). But there are loads of big blogs and multiuser set ups that do use WordPress. This alone should tell you something. You can see more on the WordPress Shocase page. Examples of Drupal sites can be found on the Drupal Case Studies page and there is also Blue Drop Awards that demonstrate the best of Drupal sites out there.

Learning about WordPress and Drupal

• There are plenty of free resources online for learning about both platforms. But I’d say the Drupal community has more. But then again, there’s a lot more to learn. If you want to get personal training, a good place to start is Lullabot or the Acquia training page. There are also several podcasts worth listening to and several sites with collections of screencasts (both free and paid).
• Both projects have good documentations (although both have different strengths and weaknesses). Drupal developers particularly appreciate the detailed documentation of the Drupal API. But beginner users will find much use for the Drupal Documentation pages. WordPress has the Codex that is a very comprehensive guide. Both are community built and maintained. Both also have forums for discussion. But if I have a problem, I start by Googling it.
• There are two large DrupalCons a year, one in Europe and one in the US. Plus there are many Drupal Camps and other smaller or specialized events. One other notable conference is Do it with Drupal organized annually in the US. WordPress has a more smaller events happening regularly around the world with WordCamp. There is also a specialised conference on WordPress economics called Pressnomics.
• Both WordPress and Drupal are fully OpenSource and developed by the community. But I’d say the Drupal community is more active. There is one key company in the WordPress world (Automattic) started by its founder but its equivalent in Drupal (Acquia) is a bit less dominant.

Background: My story of a Drupal and WordPress love hate triangle

This post has been inspired by several things but it was most immediately triggered by a Twitter conversation I had with Dick Moore.

I have been using WordPress since version 1.5 and Drupal since version 4.6. But Drupal has always been my go to tool. I’ve been an active member of the Drupal community, presented at 3 DrupalCons, gone to Drupal meetups, and followed Drupal happenings very closely. With WordPress, I’ve mostly been a user, not following the community much. These thoughts have been brewing for about two years now which was when I started using WordPress seriously again after a brief Drupal-only hiatus.

But I got a more immediate jolt  a month ago when I visited an organization for whom I built a Drupal 5 site almost four years ago just as Drupal 6 was about to come out. I trained their head in how to use it to a level where he could do pretty much everything and we were planning an upgrade but postponing it until all the modules were ready to go. But then I moved (providing occasional email support) and he left. So this organization is left with a site that works just fine but it would cost as much to upgrade as it did to build it in the first place (maybe even more). So they sheepishly told me, they were thinking about moving to WordPress. I astonished them (and myself, to be honest) when, only after a brief pause, I wholeheartedly recommended this option. They had found that some of the functionality we chose Drupal for was being used that much and some of the downsides were making it a pain to train people in its use. So the move would mean some compromises but it would mean a more stable long term web presence with easier training and more reliable upgrades. And the move is probably going to be cheaper and more feasible. Plus, there’s probably more WordPress talent in the area, than Drupal talent which is much more high demand.

To be fair, there’s another Drupal site I built (version 6, this time) which has not been upgraded to Drupal 7 (partly because of cost and partly because of the module availability) but I would certainly never recommend that they switch to WordPress because of their needs. But they will have to face the not insignificant cost of upgrade to Drupal 7 or 8 eventually.

Finally, there are my personal sites. DominikLukes.net has been moribund for 2 years because I focus all my personal blogging on the Wordpres sites (I have three active and three inactive blogs running off a single site). I finally decided to upgrade it but when I looked at the site more closely, I realized that I can probably replicate it in WordPress with about as much effort as upgrading it to Drupal 7. This post is part of my deliberations about it.

I have three Drupal 5 sites that are pretty much static now, so I just turned off comments and user registrations and will keep them as is. There’s one low-use Drupal 5 site, that I run for an organization, that I’m considering moving to WordPress.

I have 2 static sites that I was thinking about moving to Drupal but will make WordPress now.

Last and these days least, there’s Bohemica.com. My first domain, my first proper site (I had a few static sites earlier). I had such high hopes for it but it went down (with Drupal 5) the other day so I decided to rebuild it in Drupal 7. But it will have to be from scratch – the upgrade would just be too messy. But it’s certainly not a candidate for WordPress.

So you can see, this is not idle chatter. WordPress/Drupal decision making has been very much a part of my life. Hopefully, it might help others make their decisions.

Looking at this. I obviously have a website problem. Building them is not even what I do. I’m a linguist and an educator. So I can only conclude as I should have started: Hi, my name is Dominik and I’m addicted to building websites.

Related links

Many people have written on this subject. Here are some that I have found since I’ve written the blog post.

• 17 Reasons WordPress is a Better CMS than Drupal: Makes similar points to mine but I think generalizes the advantages of WordPress over too many types sites. Probably the most pro-Wordpress of the lot, from a Drupal exile. It’s 2 years old and surprisingly still relevant. Gives the New York Observer as another large site running WordPress. It is notable that they switched from Drupal to WordPress.
• WordPress vs. Drupal: The Prize Fight!: This is a more recent comparison that makes similar points to mine in much less space.
• Winner Takes All: WordPress vs Drupal vs Joomla!: Another comparison from 2012 covers similar areas and throws Joomla into the mix. Concludes very much the same. WordPress for simple sites, Drupal for more robustness and flexibility. Not much point to Joomla!
• WordPress vs Drupal – The Saga Continues: This one is actually written from the perspective of the Drupal developer. Again, draws similar conclusions. Sometimes Drupal is too generalized a tool to make it easy to use out of the box.
• Why Drupal Is Much Better Than WordPress: To redress the balance, this one comes on the side of Drupal but very much from a business oriented perspective.
• Why I Switched From Drupal to WordPress: Finally, a post from a Drupal to WordPress switcher.  This one is much more balanced. What resonates with me is the admission that they chose Drupal for the power and flexibility (like me) but found that they didn’t really need it and the price for it was too high.