Between a rock and a hard place: My experiences with Drupal & Wordpress

A while ago, I moved this blog and the other site that I help to run, on to Drupal. After going through various nightmares (the other site had first moved from Blogger to Wordpress.com to Drupal 6 to Drupal 5 to finally settling down with Wordpress 2.5), this is where things stand: This site currently runs Drupal 6 on my own server, while the other one is on Wordpress, on a different host.

The simple and important conclusion for both products is as simple as this: if you intend to make a living running sites that are powered by either software, ensure that you have the patience/tenacity to understand how the software works or find someone to do it for you. Publishing, on a professional scale, is still far from being "push button publishing." Below are some of my observations:

Ease of Install: The out-of-the-box (OOTB) experience for both Wordpress and Drupal is excellent. The only requirement for both is for you to know the database-specific details, once you unzip/untar and upload the files into a directory. While Wordpress, being MySQL-only, gives you only that option, Drupal's installer detects available database support for PHP on your host and it is up to you to select which one you would want to go with. Click through a few screens on both and you'll eventually land up with an admin user and a password in the case of Wordpress and a password set by the user in the case of Drupal.

Configuration: Wordpress supports clean URLs OOTB, provided your host allows you directory level .htaccess. Drupal follows a similar pattern, but I have had trouble getting it to behave with Nginx in anything other than domain/sub-domain root. For descriptive URLs you will have to use the "pathauto" module in Drupal, the "clean URL" module will only display the URLs without any cruft.

Drupal has a pretty comprehensive caching module that works OOTB. You can also set different levels of caching (disabled, moderate, aggressive) and also enable or disable GZIP compression on the pages. Wordpress will GZIP compress files if mod_gzip is enabled on your host. Any other forms of caching would require you to install plugins, which is highly advised if you get good traffic on your website.

Ease of use (admin): This is one major area where both suck like hell, with the only positive being that Wordpress sucks marginally lesser than Drupal. Administration screens are found more by luck than by intent in both cases (more so if you tend to use a lot of plugins in the case of Wordpress) and Drupal's administration UI is something that rightfully belongs to the age of the cavemen.

Drupal's modular format also comes to bite users very hard in the ass in the case of modules (known as plugins in the case of Wordpress). To get a module running you need to follow this strange process, which has screens hidden in different areas: unzip & upload -> enable it (site building - blocks)-> set permissions (user management - permissions) -> change settings (go to /admin, do a find and pray that it is there somewhere) -> add visibility through 'blocks'. Different modules have different ways with permission settings and getting a whole lot of changes done on a Drupal website will show up a click trail that would probably average at some 2-3 clicks per task.

Wordpress is marginally better on this count, where you have only two places to poke around, either on the "manage" page or on the "settings page." It can't be really difficult to change the core of both platforms to alter the workflow in the following manner: Admin -> Plugins (list) -> Plugin (individual)-> settings | permissions | enable/disable.

Creating and maintaing user lists, category lists are other administration functions that a user needs to deal with while running a website. Drupal here has better flexibility (user groups, group-level ACL) and finer-grained control, while Wordpress suffers from its roots as blogging software on this count. Wordpress allows you to create new users, but you can't change the user-groups that are fixed within the system. It is also not made clear anywhere what each group status is meant to signify, other than that "admin" level users get unrestricted access to the website.

As far as administrative messages go, I have not yet encountered a single error in Wordpress, while Drupal spits out some of the most horrific looking stuff in your face when it decides to barf on you. Granted, that some of the errors are due to my usage of PostgreSQL, which is not maintained as actively as the MySQL version of Drupal (so much for database abstraction), but the moot point is that it should show me reasonably friendly error messages than to tell me function x failed at line no 354 which is an inner join to some table in the database.

Ease of use (user): Trick question of the day: which format would you like to post a comment today -- full HTML or filtered HTML? As a user, why on earth would I want to know or make that choice? And that is exactly what Drupal throws in the face of a user unless you, as an admin, can somehow manage to turn it off, the setting for which (no prizes for guessing), I have not been able to find out yet. Wordpress has a much easier UI to do the same. Mind you, it is not that Drupal won't allow you to post a comment if you don't specify the input format, but why show something that 99% of the users will have a hard time understanding anyway?

Both Wordpress (default is set to off) and Drupal has self-registration processes which are easy to follow. Whle Drupal 6 allows OpenID logins OOTB, Wordpress will require the usage of a plugin to accomplish the same. On login, the Drupal user is given a subset of the main administration navigation menu (depending on the ACL) and Wordpress does the same by following the access restrictions defined in the ACL groups (administrator, editor, author, contributor or subscriber).

Moderating comments is a considerably easier process in Wordpress compared to Drupal. If you allow moderation-free commenting on Drupal, be prepared to be swamped by a tidal wave of spam, which the Akismet module did nothing to stem. Eventually, I had to switch to CAPTCHAs, which has held up well this far, but I have no idea how it would fare on a site with good traffic.

Ease of maintenance: Drupal allows you to do much much more from the administration panels towards maintaining the website than Wordpress. The "reports" section of Drupal gives you comprehensive updates and log trails of usage. Updating modules on both Drupal and Wordpress follow the same process -- download, unzip and upload, though Drupal will ask you to follow it up with a visit to the update.php script once you are done.

Wordpress has excellent plugins to back up the entire database and create snapshots on a daily basis that can even be emailed. Drupal, unfortunately, has no such facility. I use dual rsyncs (one for the directory structure and other for the DB dump) to keep an offline back up of the website.

Ease of customization: Wordpress theming is the old Blogger style templates on steroids. There is really no template here to speak of and you can pretty much execute any PHP code in a Wordpress template, leaving security as a valid concern if you are fond of installing templates from everywhere. Drupal themes on the other hand will force you to poke yourself in your eyes with hot sharp pointed iron rods before you get to master them. Accomplishing things with it would require you to understand "hooks" and other vagaries of Drupal's core before you can even come anywhere close to it.

That said, the modularity of Drupal allows you to slap on other modules to link up with other software than Wordpress. This allows you to extend Drupal much easier compared to Wordpress, even though this is not really advisable since it would also overload your Drupal installation with another zillion queries than what it already does.

Custom views are possible in Drupal through the "views" module, while it is not possible at all in Wordpress (I am yet to find a way to have a page on Wordpress which will list all categories which does not involve significant hacking). The important thing, though, is that in both cases it is impossible for the average user to muck around with it.

Conclusion: If you ask me, either solution is not quite right if you want to do a full-blown publishing stack. Wordpress will allow you to hit the ground running in the shortest period of time, with the least of technical requirements at your end. With time, and more complicated requirements, Wordpress will start to struggle to support you. While there are numerous hacks out there which will allow you to run Wordpress as full fledged content management system, the truth is that Wordpress is not really a CMS and that fact tends to shine through when your requirements end up being more complicated.

On the other hand, Drupal is a tough one to learn, understand and to make it dance to your tunes. It is impossible to run it without an experienced technical hand at your disposal all the time and customizing it is even harder, which most Drupal hands will say is the "obvious" since it is considered more a framework that enables a content management system than being a full content management system by itself. But the fact is that Drupal, where it stands right now, is a bit of work that is a whole lot better than what a lot of commercial systems are at right now.

They have done 80% of the things right in Drupal, with another 10%-15% of effort in the right direction, it would absolutely rock and enable professional publishing of content a breeze at a near-zero cost. Maybe Gnomepal will enable this at a much later date.

But if you were to ask me for a clear winner, I would definitely pick Drupal over Wordpress because I manage it on my own. Take the last part of the equation out of it and you'll see that there is really no clear winner, it depends entirely on what your requirements are going to be.

Platform Details:

Fatalerror.in
Drupal 6, PHP5 (FCGI), PostgreSQL, Nginx on Slicehost.

Lawmatters.in
Wordpress 2.5, PHP5 (mod_php), MySQL, Apache on Webfaction.