Drupal vs. WordPress: Round 2
I took a look at Drupal vs. WordPress earlier, and the post got long enough that I cut it off. Here are some more thoughts.
Theming and Design
Both systems are somewhat similar in the theming department, and they use similar syntax. Coming from WordPress, learning to theme in Drupal was a very short learning curve.
I'll now look at two areas, one of which WordPress wins, while Drupal takes the other.
The first is Drupal's blocks vs. WordPress's widgets. In many ways, they're similar (thought blocks came first). Both offer the ability to add snippets of content such as plain text or menus, in different areas within a theme. Blocks, though, are more flexible, more extendable, and also come on-board with more configurability in terms of showing or hiding them for certain pages, user permissions, or other criteria (see the Context or Panels module, for instance). That said, I'm sure Widgets will improve quickly.
Now onto the design market for paid (and free) themes. WordPress clearly wins here, so far. WordPress attracted a community of designers far earlier, and has orders of magnitude more themes, especially nicely-designed ones, available to download and install directly.
More about Flexibility and Modules/Plug-ins
I'm going to take WordPress apologists on here. Often, in forums or blogs where the two platforms are discussed, WordPress folks will cry foul at the idea that Drupal is more flexible or powerful, saying "There's a plug-in for that!" This is recently true in the area of content types, since WordPress 3.x came out with the concept of custom post types. The community has responded, building an ecosystem around this to extend it, and I think it's great. However, WordPress's core, at its most fundamental, simply doesn't have the level of abstraction as Drupal's core entity API, allowing true flexibility when creating custom fieldable entity and content types; you can call custom post types "custom content types", but at the end of the day they're still posts, which is great for blogging but simply nowhere near as abstract or flexible as Drupal entities. And not that they're designed to be; that's not what WordPress was for.
This takes me back to what I said in my last post, which is that WordPress plug-ins are more often bolted-on functionality—often ready-made with the exact functionality they're designed for. Drupal modules, meanwhile are more often "lego blocks", by which I mean they provide less polished functionality but are far more flexible. One blogger described WordPress plug-ins as "ready-made meals" and Drupal modules as "ingredients", which I think is apt. Let me jump back to the example of calendars, which I passed over quickly last post. In WordPress, installing a calendar plug-in gives you a ready-made calendar. You have some ability to customize it, but mostly it "is what it is", and it may not provide deep integration with, or fundamental altering of, WordPress core. By contrast, the Drupal Calendar module is built on the Views and Date modules, which respectively create custom lists of content (or entities, really) and allow site builders to add Date fields to any entity type. Thus, a site's calendar(s) can feature any type of content or entity that contains some sort of date field, which is a deeply-integrated type of functionality. But, like many WordPress vs. Drupal differences, the Drupal Calendar module requires quite a lot more work to set up and get going, which could be considered its downside, depending on your perspective.
Let's jump back to custom entity and content types in Drupal vs. custom post types in WordPress. Building on my last paragraph, custom post types are a nice addition but they simply are, in essence, "bolted onto" the post system to make it more powerful, while not fundamentally altering WordPress data types. The introduction of entities in Drupal 7, by contrast, was a deep change from everything that came before. Which, unsurprisingly, resulted in far higher upgrade costs from Drupal 6 to 7... what's new?
