Recently, a prospect that I truly think would be better suited with Drupal has asked me to make the case for it (since she’s inclined to otherwise go with WordPress.) So it’s forced me to really think about this topic and do some homework so that I could articulate the difference from the point of view of someone who has to make this pretty important decision without getting lost in the technical intricacies of the debate.
ONE IS NOT BETTER THAN THE OTHER
First, let’s dispense with the notion that one is better than the other. They both have their pros and cons. It’s about what is the best fit based on the need. But even then—as I Googled information and graphics about the matter, I got a bunch of charts with features as either supported or not supported in one or the other.
Folks, that’s the wrong way to look at this question.
DRUPAL VS. WORDPRESS IS NOT A QUESTION OF “BUILT-IN FEATURES”
At the end of the day, both systems (and arguably any modern-day CMS) has a plethora of modules, plugins, or whatever that can support whatever feature you may desire. In this case, since they’re both open source and can be customized to any extent, you can commission sort any of custom functionality that you can dream up (and afford.) To compare these systems as a sum of their features is the wrong paradigm in which to consider the question.
I would argue that the question as to Drupal versus WordPress comes down to the caliber and complexity of your needs, and your willingness to mold your needs to the platform versus having the platform molded to your needs.
A CMS VERSUS A “FRAMEWORK”
Let’s peel back a few layers to better understand what these things really are. Drupal and WordPress are often compared on the presumption that they’re just different versions of the same basic thing: a content management system (CMS). Not so. WordPress is a pretty straightforward CMS, true. It’s a web-based software application that does just that: helps you manage your content. Drupal, on the other hand, is an application framework with a CMS built into it as one of the applications that comes with it out of the box.
WORDPRESS IS THE MENU. DRUPAL IS THE KITCHEN.
What’s the difference? It might help if we use an analogy. Let’s think of your website as a 5-course meal. Your entrée is the bulk of your dinner and what drives what you ordered for the most part. In your website, the actual content publishing components and core architecture of the website—that’s your entrée. But you have other parts of your dinner that help round it out. Your appetizer might be an event calendar. Desert could be a donation form. Get the idea?
WordPress is like a menu from which you can select what suits you. It gives you a variety of pre-defined dishes to choose from (within a limitation that the Chef defined.) You can pick and choose and put together your own meal to suit your fancy. But you’re limited to what is on the menu. And sure, you can probably ask for a substitution or two (ie, feature customization), but if you go crazy, the Chef (web designer) take issue with you (and start charging you through the nose for trying to substitute your suggestions for his recommendations. But that’s a whole different story.)
Drupal isn’t the menu. Drupal is the kitchen. Yes, Drupal has a menu too. But the power of Drupal is that it provides the work space, the tools, the raw ingredients, and the methods a Chef would need to whip up any meal he desired—from something simple like a burger and fries to the fanciest of French cuisine. Frameworks are like kitchens. They’re not the actual menu items (website features). They’re the means to create any menu item you want.
A RESTAURANT VERSUS A CATERER
To extend the analogy, if you and your date go to an Italian restaurant, you’re going to be offered a menu of all Italian food. And if that’s what you’re looking for, and it’s all your looking for, then great. You’re probably best suited there. But what if things are more complicated than that? What if it’s not you and a date, but you’re trying to plan for catering for a weekend conference of multiple meals, multiple locations, different styles, different sizes, etc.? (Ie, what if you have multiple web properties or sections of your site that speak to different audiences, maybe need to have their own branding or style, need to be managed by different people who use different processes and have different abilities, etc.?) You don’t necessarily just want an Italian restaurant in this case. You want a catering company (a web development shop) who has a kitchen and can tailor menus to suit your needs—who can recommend what menu items go best together for any given meal, and who can accommodate the fact that you want all your meals to follow a common theme while still given each one its own flair (and who can figure out creative ways to re-use ingredients (code) to keep costs down and get things out of the kitchen faster.)
A catering company is probably overkill if you and your plus one are simply in the mood for Italian. But hiring an Italian restaurant to try to coordinate a big event with a lot of different meals and complex relationships between them is equally ill-suited.
PICKING THE RIGHT PLATFORM BASED ON YOUR ORGANIZATION
And such is the crux of the WordPress versus Drupal debate. If your an organization is fairly one-dimensional in that you simply want to publish information in an orderly and timely way on your website, you’re probably better served by WordPress. It’s simpler. Easier to get up and running. Usually cheaper to develop. And despite what any list of ‘included features’ might tell you, probably as a plugin that can accommodate whatever basic functionality you’re looking for.
But if you’re a larger organization with multiple departments or offices—all of whom may not agree on a single web strategy, and you have a lot of content that relates to other content, and you have several levels of people who may want to manage the site, then Drupal is probably a better foundation for you. It will give the Chefs a lot more flexibility in how they might be able to accommodate specific needs and how then interweave different ingredients and menu elements to create common themes despite different menus for different purposes. These Chefs are also (hopefully) more skilled at helping you plan out these large catering events. They’ve done this before, and so instead of you picking random menu items from a limited number of choices, you’ll have a head chef (chief architect) who can put together a larger plan and coordinate how all the different meals will fit into that plan and work well together and come out of the kitchen on time.
SOME RULES OF THUMB FOR DECIDING BETWEEN DRUPAL AND WORDPRESS
My analogy isn’t perfect, I know. But I hope it drives home the point that Drupal is a framework upon which a web application can be built, whereas WordPress is a much simpler content management system designed to make your life easy by giving you pre-defined options that can be grouped together to extend what is effectively a glorified blogging system at heart. And if that’s all you need, then you should go with WordPress. It’s a lot easier to work with and will be cheaper to have professionally built. Pros can push WordPress further and can get it to do things that are out of its comfort zone, but still doable by a skilled developer. I would encourage you not to let the prettier interfaces and friendlier terminology sway you if you know your organization has complex needs. In our experience, most organizations north of about 50 people or that have fairly independent departments or initiatives are probably better suited to Drupal.
Technical rationale aside, Drupal is really good at things like user management, grouping things (users and content or groups of content) in organic and natural ways, and relating those groups to each other automatically (using far more advanced methods when it comes to content tagging, taxonomy, and search.) Drupal also is really good for working in third-party systems (such as CRMs, event tools, membership managers, etc.)
Drupal also is a great choice where you have multiple web properties (perhaps some under the same domain, and some with their own domain.) With all this flexibility and extensibility comes inherent complexity. (Though most of that can be abstracted to the end users and even to the site’s administrators (corporate plug: Taoti prides itself on making Drupal a bit less Drupaly for our clients so that they’re not subject to the out-of-the-box clunkiness of Drupal that often gives it a bad name.)
There is no way around the fact that if you’re after simplicity (especially if you don’t have a dedicated webmaster who can dedicate full-time attention to the website), WordPress wins.
