After 4 hours of trail & error, and consuming lots of support in IRC #wordpress, I was able to set up and bring my new personal blog online on WordPress’ latest stable release 3.0.5!

sun, WordPress?

Dave Reid inspired me to approach this challenge when he mentioned that he’d test several other systems in IRC #drupal-contribute.  Not that I didn’t play with the idea already, but Dave’s initiative ultimately pulled the trigger.

What should have been a quick intermezzo turned out to be a quite interesting challenge and adventure.  Conclusions I gathered along the way:

Note:  Obviously, my review is biased.  Most links in this post are pointing to Drupal equivalents of WordPress functionality.

Installation

  • Drupal’s installer excels WordPress’ installer.  Looks like we’ve not only catched up, but also went ahead.  However, Drupal’s text formatting, especially of file references and command lines, needs work though.
  • WordPress installation ends with 11 tables in the database.  Compare that to ~74 (?) of Drupal.
  • Had to tweak a couple of mod_security rules in order to log in to WordPress.
  • There’s no .htaccess file by default; WordPress only tries to create it when configuring Permalink (URL alias) settings.  Of course, that fails.  Without my pre-existing knowledge, I wouldn’t have been able to figure out how to make that auto-write work.  Aside from that, the interesting part is that WordPress is basically able to generate (and write) customized .htaccess files depending on its configuration.
  • After installation of WordPress, there’s demo content (a static page and a [blog] post).  I edited the page, deleted the post.  I always objected to do the same for Drupal, still not sure whether that is actually useful.

Post-Installation

  • You end up in WordPress’ admin interface.  No idea what the actual site looks like.  Minus points on that.  And most of you probably know that I’m heavily opposed to front-end/back-end separation in general – Joomla! and WordPress always did this, Drupal didn’t attempt to do it until D7, and I still state that the fundamental idea and direction is utterly wrong for many reasons – which do not fit into this post.
  • WordPress’ default theme comes with a range of customizable theme settings, including the background color/image, and an “header image“.  But the point it gets really exciting is that you can upload a 2MB+ file for the header image, and it’s not only automatically scaled down to ~940px, but you also get a JS-driven image crop tool right afterwards to select the image part that shall be displayed as header image.  The original file is not stored however, so you can’t change your mind without re-uploading – minus points on that — after granting countless of points for the image upload and crop functionality in the first place, of course.
  • WordPress truly excels Drupal with its built-in extension browser.  Not the browser itself, but merely the fact that you can search themes and plugins from within your site.  There are no filtering or sorting options though.  Searching for “twitter” yielded a stunning result of 1,200+ plugins.  wordpress.org isn’t any better.  Over there, plugins can be sorted by relevance, popularity, and user rating.  (Note that WordPress has no notion like tablesort built-in, so all you get is a pager.)  None of the options improve the results.  Asking others in #wordpress for how that amount is useful in any way and how they’re choosing plugins for their sites didn’t result in any better conclusions, other than to refine your search through additional keywords and just trial & error.
    • Took me more than one hour to figure out which plugin I should use for the simple Twitter feed widget in the right sidebar.  If you ever faced a scenario like this, you will understand my strong opinion and objection with regard to allowing duplicated projects on drupal.org (unless there is a very good reason for the duplication).
    • The uploader/installer worked flawlessly, both locally on Windows and remote on Linux (via FTP and SFTP, both built-in).

Administration

  • WordPress’ admin interface consists of regions and widgets (blocks).  A few simple settings pages only consist of plain page content, but most other admin pages entirely consist of blocks instead.  You can not only collapse and expand, but also drag and drop all of the blocks on a certain admin page (type) to your personal liking – which includes moving (jQuery UI $.sortable) blocks from one region to another, and all of this sticks.  Reminds of Panels, but affects the entire page.
  • The admin interface permanently shows a navigation menu in the left sidebar (similar to Admin module), whereas top-level links can be expanded (one level) to see the links below by clicking on special icons.  Takes a bit to grasp this.  Obviously, the fundamental pattern and idea only works with a very limited set of top-level and sub-level links, so it doesn’t leave much room for modular expansion and isn’t very insightful for new users either (unlike Drupal’s Administration menu module, which – as a matter of fact – was originally derived from Joomla’s administration interface).
  • A different color scheme for the admin interface can be applied to every user.  Handy, but probably over-sized and too inflexible in the long run.
  • Plenty of unexplained options and functionality everywhere in WordPress’ admin interface, without any tooltips or whatsoever.  Accessible mode needs to be toggled per page or globally in the user account.  Drupal 7 wins on both fronts here.  Overall, the user interface and help systems of WordPress and Drupal seem to be on par though.
  • Usernames cannot be changed in WordPress.  Each user has an additional nickname, which can be changed, as well as a real name.  Additionally, each user has a display name, which can be configured individually to be the username, nickname, first name, last name, or full name.  The display name is nice, but overall, the username/nickname separation is extremely confusing.

Usage

  • WordPress comes with a range of convenience content authoring and publishing features built-in:
    • A WYSIWYG editor (TinyMCE) with a custom theme and plenty of additional editor plugins — actually, now I finally understand.  Apparently, it looks like acquia’s Drupal Gardens merely tries to resemble all of this in Drupal…?
    • A combination of Media, Insert, and Inline modules as well as advanced plugins to support extremely rich uploading and inserting of images, videos, audio, and other media via the editor.  The entire uploading and management of media happens in jQuery-driven dialogs.  Files can be uploaded via swfupload or native browser uploads; you can switch methods in a single click.
    • Pathauto, directly shown below the title field, and you can edit the alias while editing in a neat, JS-driven UI.  WordPress confronts users with geeky terms like shortlink; i.e., the internal/system path of a content piece.
    • Drafts and revisions, a trash bin, publishing status, as well as publishing schedule workflows functionality is built-in.  Didn’t see diffs between revisions yet, but might be missing something.  (After all the hype and buzz for D7, I actually expected a more awesome user experience in WordPress…)
    • WordPress prompts you whether you really want to leave a page (form) after editing.  But actually, that’s TinyMCE’s (confusingly named) Autosave extension, not WordPress.  Hence, just enable the plugin in Wysiwyg.
    • Built-in support for pingbacks and trackbacks, auto-closing comments after a configurable time-frame, comment notifications, only publishing comments of already known (anonymous) authors, automatically unpublishing comments containing more than X links, URL/IP/author/text blacklists automatically unpublishing comments, as well as author pictures via Gravatar.
  • Content is created upon editing, not after saving.  You have a new content (draft) right after attempting to create a new post, smart! Even more funky, it automatically saves a new revision every couple of seconds.  Holy cow.
  • WordPress allows you to preview your draft version (new or existing post) in the front-end, by appending a ?preview=1 parameter to the URL.  Doesn’t take page additions into account though (such as widgets/blocks; e.g., comments, comment form settings, etc), but regardless of that, it’s very helpful to see a preview of the final result.
  • WordPress content supports a notion of Custom Fields, which basically is a key/value store for arbitrary meta data to input per post and simply output in the theme.  Drupal obviously beats that with its fieldable content types and entities, allowing you to store data in a more meaningful way.
    • Closely listening to #wordpress during this adventure additionally clarified that WordPress’ support for custom content types lives in code only.  No UI for that yet; i.e., comparable to Drupal 5.
  • Themes are able to plug into the content editing form to allow customization of page/post-specific theme-related settings.  Wouldn’t have noticed that if I hadn’t installed the semi-commercial, but featured Platform theme.  That’s interesting, because stuff like author information and regions or blocks to show or hide indeed belong to the theme system, and allowing per-page/entity customizations for a particular theme makes sense.
    • No idea what “featured” actually means, but seems to be something along the lines of Drupal’s golden contrib idea — definitely useful for newcomers.  I already learned that there are gazillions of other themes, but to test-drive, I just simply wanted anything non-default, community-approved, and working.  Let’s adopt that for Drupal.
  • WordPress has built-in support to submit new posts via XML-RPC and via e-mail; the latter through a full-blown POP3 mailbox e-mail handler, so you can basically post new content from anywhere.  Drupal removed the built-in Blog API support from core for D7, and the mailhandler module was never really used outside of drupal.org (and even there only years ago).
  • Content supports both Tags and Categories at the same time.  No idea what to use.  Learned from friends in #drupal that they’ve seen Tags being used more often on up to date WordPress blogs…
  • While typing this blog post, some JS in WordPress seriously eats my browser’s performance. :(  And yes, a smiley filter is built-in, too… :-/

Support

  • Although similar in size of users, the IRC #wordpress channel is much more silent than #drupal.  Also, as mentioned before, there are many more questions (stupid, like my own) from users about Which plugin to use for xyz?
  • WordPress has extensive and elaborate online docs about individual topics, which explain all details about usage but also implementation.  Although Drupal has its API documentation readily available, this level of detail is hard to find in drupal.org handbooks, which is one of the things we want to improve for Drupal 8.
  • Had to be reminded by folks in #wordpress that WordPress is not backed by Automattic, but the WordPress community.  Only the hosted wordpress.com is commercial.  Let’s make sure that this kind of confusion never ever happens with acquia and Drupal.
  • Oh, and WordPress has an awesome logo and the logo is provided extremely professionally.

In the end, I can only encourage everyone to attempt this (or a similar) challenge on your own.  It really helps to understand differences and similarities in approaches between open source content management systems, and see how others are solving or struggling with the same issues that we also have.

There are a lot of things that we can learn from.  Serving both as positive and negative examples.  The intention and goal should not be to simply copy features — which unfortunately seems to be the case for many of the new user experience and usability features in Drupal 7, as far as I can see. — Instead, we want to learn about good and bad ideas, patterns, and techniques, and should always discuss the fundamental idea from scratch for Drupal.

This post mainly focused on initial experience and usage.  What I’m even more interested in is an in-depth review and analysis of WordPress’ API design, data storage, and code logic, which I might be following up on in a separate post.

for Drupal
Tagged with:
 

10 Responses to WordPress vs. Drupal

  1. [...] This post was mentioned on Twitter by kylemathews and Isaac Sukin, Daniel F. Kudwien. Daniel F. Kudwien said: Review: WordPress vs. Drupal http://bit.ly/f52dQ4 [...]

  2. Dave Ross says:

    I don’t think it’s fair to say WordPress’s custom content types live in code only. Like Drupal has CCK, there’s Custom Post Type UI and Custom Field Template that let you create “post types” and assign fields to them. The fields get stored in the key/value metadata fields behind the scenes, but Custom Field Template provides a nice front-end for data entry.

    I don’t think a lot of WordPress users take advantage of “post types” yet because there isn’t a built-in UI, so they’re probably still living in the days where there weren’t UIs for setting this stuff up.

    • Like Drupal has CCK, there’s Custom Post Type UI and Custom Field Template that let you create “post types” and assign fields to them.
      [...]
      don’t {…} take advantage of “post types” yet because there isn’t a built-in UI

      Right, that’s what I meant — the basic API exists in code, but the UI is only available through a third-party plugin. From a technical standpoint, that’s comparable to Drupal 5′s support for custom content types.

      Drupal 7 no longer requires an additional module; the API and UI for custom content types as well as a quite heavy notion of fields (which in themselves are of certain, extensible field types) is built-in.

      Drupal 7 also introduced an API for entity types. A content, comment, tag/category, user, aso. is an entity type, whereas a “Post” and “Page” is a so called bundle of the entity type. Each bundle can be enhanced with fields.

      • Dave Ross says:

        Very true. I’ve messed with D7 a little, but we’re sticking with D6 for now until Panels/CTools/Panels Everywhere are ready. Forgot CCK is built-in now.

  3. I bet we could build an install profile that mimics WordPress functionality (easier now that you’ve narrowed down most candidate modules). It’d be sweet if it could even include a way to somehow import some/all of the content from an existing wordpress site.

    An yes, there seem to be none at Drupal.org.

  4. Luis says:

    Hi. Interesting article.
    I’m doing a series of videos which try to explain exhaustively the capabilities of wordpress. Starting with its database.
    I have a simple question: What is the benefit of having only 11 tables? For example joomla has 33 tables and drupal 73 tables however wordpress is almost always the winner of the top ranks.
    Please tell me your opinion about it.
    And if you can see my videos and tell me your opinion.
    youtube video: http://www.youtube.com/watch?v=86cqTwGhBm0
    vimeo video: http://vimeo.com/22973629
    Thanks in advance.

    • The amount of database tables right after initial installation is not really an important benchmark to do. It might provide a hint about whether functionalities/features of the system are cleanly separated or not. As in this case, it’s also an indicator of how much default functionality you get out of the box. Too many database tables might be hard to administer for casual users, who are commonly using tools like phpMyAdmin.

      The values need to be understood. Without in-depth background information, there’s no meaning to them.

      In Drupal’s case, the ~74 database tables refer to the Standard installation profile, which installs ~28 modules. This means you get a full-blown system that covers most content management system functionalities – and those features are cleanly separated (modular); i.e., you can disable and enable most modules to your liking. However, Drupal also provides a Minimal installation profile, which only installs ~7 (absolutely required) core modules, leading to much less database tables. You can enable and add further modules/functionality tailored to your use-case. This means that you can replace a certain functionality in Drupal with a different one without having to care for the built-in or potentially hard-coded functionality. It’s important to understand that stuff like comments, taxonomy (categories/tags), and more is considered optional (use-case specific) in Drupal.

      In WordPress’ case, the 11 tables basically denote that there’s a lot of different functionality squeezed and intermixed into the same data/schema. That is, because WordPress provides a lot of features, and everything you enter or configure somewhere needs to be stored somewhere in the database. You will likely have a hard time to disable, extend, adjust, or manipulate the default behavior or storage of some particular subset of data belonging to certain functionality in WordPress, because it is tacked onto some other data/storage, and that other data very very likely has a hard dependency on it.

  5. Mark says:

    Yeah, I think it depends on what you wanna do… the purpose of the site.
    I have used both Drupal and WordPress for 6 years now and still love them both for different reasons: Drupal for its power with many various content types, and WordPress for its simplicity in blogging sites. But I must admit, you don’t have to do so much damn hacking with WordPress (plugins are well-maintained, Drupal’s aren’t) and when you do have to dive into the code, it’s real easy; I spend far less time when I build a WordPress site than when I need to build a similar site using Drupal.

    I’ve spent the last year exclusively on Drupal, but now I’m changing back to WordPress. Better support, better plugins, much better for e-commerce – and now becoming more powerful and flexible with multisite, buddypress and custom post types.

    But I still love Drupal, it’s just losing ground.

  6. Matthew says:

    I’m a noob and I’m trying to figure out which one to use. This article has made it clear that although it’s more powerful, I don’t know a thing about Drupal. I’m totally going to get started with WordPress and try to learn Drupal later.

Leave a Reply to Mark Cancel reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

By submitting this form, you accept the Mollom privacy policy.