Drupal vs. WordPress: In Which I Put it in Perspective (and Defend Drupal a Little)

As an open-source PHP developer who uses both WordPress and Drupal (although, currently, I use Drupal significantly more), I always assumed we were all on the same team. So I was a little taken aback at the level of vitriol leveled toward Drupal from the WordPress community in various blog comment threads. (Although, heh, given that they *are* comment threads, which bring out the worst in people, I shouldn't be surprised.)

So, look, here's the thing. We all specialize. We all have favorite tools, and over time we generally build a client base that allows us to focus on those tools. That's all fine. But specialization and preference are not in themselves reason to believe all other tools "totally suck", which is the impression I get from many of the WordPress "trolls" on the comment threads and elsewhere.

So let me go through a couple of dimensions of this issue.

1) Expectations

I encounter many WordPress users who have a story something like this: "I am a WordPress developer. I used Drupal once or twice and it was horrible! It took lots of time to do simple things/was not usable/used lots of server memory/had horrible themes." OK. Yes. There's a kernel of truth in most critiques, and this one is no different. However, it's mostly a matter of expectations. If you are used to installing WordPress and being quickly ready-to-go out-of-the-box, you'll be disappointed. But the fact that Drupal takes some configuration, and, for instance, doesn't come pre-packaged with a WYSIWYG editor, doesn't mean Drupal "sucks" (in fact, there are reasons for no pre-packaged WYSIWYG) any more than WordPress's lack of content- and entity-type flexibility means WordPress "sucks". Both have reasons for why they are the way they are, and it is up to you, as an intelligent developer, to pick the best tool for the job.

In my view, you can do the "simple version" of many things in WordPress. For instance, there are CRM, e-commerce, and calendar plug-ins for WordPress, and if you set your expectations accordingly—i.e. you are not expecting to do something too far out of the typical use-case—WordPress will probably do fine. For example, WordPress e-commerce plug-ins can work very well for a run-of-the-mill online store that sells merchandise, but is almost definitely sub-optimal (and maybe completely underpowered) for a nonstandard e-commerce setup in which, say, an online membership purchase initiates a cascade of secondary and teritary functions throughout the site.

Now, let me try another angle on this. I am not a Rails or Django developer, and there are good reasons for this, mostly centering around (a) my abilities as a developer, and (b) the types of clients I work with. At my level, I find Drupal easier to do the types of things my clients want, but—not to belabor the point—I would never say that Rails or Django "suck" because both take considerable more time and expense to set up. Look, here's how things work. The average WordPress site is less complex than the average Drupal site. And the average Drupal site is less complex (and less expensive) than the average Django or Rails site. All of these tools/CMSs/frameworks have their place for what they're for. As a Drupal developer, I recognize and respect this fact about the frameworks "upstream" from me, complexity-wise, and I would ask WordPress developers to hold the same respect for that which is "upstream" from them.

Here is how I would characterize the "sweet spot of each framework I have mentioned so far:

• WordPress: blogging (obviously!), relatively simple publishing and content management. It is best in situations where they are fairly straightforward relationships between people and the content they are producing.
   
• Drupal: a good hybrid solution in which, say, your client needs to manage public content in a "traditional" CMS setup, in addition to non-run-of-the-mill e-Commerce, membership management, Contact Relation Management (CRM) capabilities, human resources, asset management, e-mail marketing, and/or complex access control. This niche is admittedly smaller than the previous one, which goes a long way to explain the smaller Drupal market share—not (and I realize I am a broken record here) because WordPress is "better" or Drupal "sucks" in some absolute sense.
   
• Custom frameworks (Rails, Django, CodeIgniter, etc.): For more "pure web applications", for instance web apps that feed mobile apps and are not in a meaningful way "websites", situations where the data model is more fluid than what a CMS wants to shoehorn you into, and/or when your client has the budget to pay for the complexity.

So set your expectations properly.

2) Assumptions the software makes about you

Unsurprisingly, WordPress makes by far the most assumptions about the websites and users. For instance, it comes pre-packaged with two distinct content types—pages and posts—each of which are purpose-built for what they're for. This is quick on the setup, but rigid. It is true that WordPress 3.x allows "custom post types", but the data structure is still relatively purpose-built and geared toward publishing. Drupal's content structure consists of abstract content entities called "nodes", which can be blog posts or pages, but are designed from the ground up to be extensible and make few assumptions about what they're for. So node types could include job postings, forum posts, email marketing campaigns, location listings, HR documents, or anything one can imagine. WordPress's posts are convenient, but I cannot imagine trying to shoehorn all the data types I just mentioned into "post types". It might not be impossible, but would feel wrong and lack the necessary flexibility.

This issue runs through the entire comparison of WordPress vs. Drupal. It is absolutely true that one can set up WordPress with relatively little learning curve, but WordPress more quickly runs into limits. These may or may not be insurmountable—you can do almost anything of you have the resources and the will—but at what degree of complexity does WordPress become more difficult to work with? There isn't a hard and fast line; it is better represented by a venn diagram with some overlapping, but mostly separate, circles, each of which represent WordPress and Drupal.

3) "Drupal requires a Developer to do things you could just as easily do yourself".

I see this a lot, often thrown around on comment threads, but rarely are hard examples or case studies given. So imagine for a moment a large website with, say, a dozen or more "separate" admin areas for different levels, or coequal groups, of employees with some type of administrative access within their sphere of influence. Imagine lots of data types that do not correspond to Posts, Menus, or Users (and, speaking of users, you need many more user roles than WordPress comes packaged with), and above that you have very important and complex content-access control points. Could you do all this with WordPress? Maybe. I don't know. What would it take to do so, how much custom coding, and to what degree would you "bastardize" the intent of the content types you were shoehorning into your needs?

Seriously here: I am sure one could make the case that it's possible to do what I described with WordPress. But could you really make the case that WordPress is better-equipped for this type of task? Could you, as people sometimes claim, "easily" do what I described in WordPress, and, crucially, do it in a way that left room for the inevitable future expansions?

Believe me, I don't say this to get down on WordPress. To make an analogy, I own a Honda Fit. I love the gas mileage it gives me. But I know there is a limit to the loads it can pull, so you won't find me saying a Honda Fit is "objectively better than" a Ford F-350, especially if pulling loads were what I needed.

4) Areas where Drupal sucks

I am serious when I say there are many things that suck about Drupal! We talk about them, and how to fix them, at Drupal developer meetups. I don't know anyone who's under the illusion that Drupal is the "best". That said, because of Drupal's inherent flexibility, many of its problems are either fixable without a whole lot of effort, or, in fact, are themselves caused by bad developers. Certainly, if a developer throws together a Drupal site and picks a shoddy WYSIWYG editor, that'll be a problem, but it obviously does not mean that "Drupal's WYSIWYG sucks", since Drupal does not have a built-in WYSIWIG editor to begin with.

Another common complaint are themes, and the "divitis" that affects many Drupal sites. Yes. OK, point taken. But that's largely a theming issue that can (mostly) be easily resolved by even a half-competent themer. Stock "base themes" include extra <div> tags, which are added in order to be abstractable, and can and should be removed on many sites. Views templates contain many layers of divs by default, but again these can be overridden.

5) Entities: The most comonly overlooked?

In debates, I often see WordPress apologists say that "WordPress is catching up to Drupal" in its power as a CMS. And it's true that WordPress has come a heck of a long way; I am not one of those people who rests on the old canard that "WordPress is just for blogging". That said, it's critically important to look at Drupal 7's entity system, as I did in previous posts. Because entities didn't exist prior to Drupal 7, which came out in 2011, I think many people, in their minds, are comparing old (pre-Entity API) Drupal to the newest in WordPress.

However, the Entity system puts Drupal head and shoulders above most competing CMSs—if your goal is sheer power and a steadfast refusal to assume to much about what the developer wants to build. Where other CMSs generally have content—and strictly-defined content types at that—Drupal's Entity system allows, essentially, any number of fieldable "things" that represent your data structure. Entities could include:

• Content types
• Comments
• Categories
• User accounts
• Registrations (e.g. for events or classes)
• CRM contacts, notes, organizations
• e-Commerce Products

...and the list is endless. Each Entity Type I mentioned can have multiple sub-types (called "bundles" and can contain custom fields (and those fields can be shared.

This system is truly what helps Drupal cross the line to what it is now: a hybrid between CMS and a thing for storing "stuff"—as I've said, organizational assets, records, whatever.

In Conclusion...

To go back to my earlier metaphor, the Honda Fit is a very fine vehicle. However, I've found my clients continually asking me to haul heavy loads, and so I have found systems that are well-equipped for that.