Evaluating Drupal and Wordpress MU

Authoring, editing, and managing official College Web sites

As part of our new Web Hub program — and in previous discovery projects (2008 | 2007) — I've been evaluating open-source content management software. Our two finalists are Drupal and Wordpress MU.

Based on hands-on experience — as well as some preliminary ranking of criteria against our goals — I have been impressed with how similar these two packages behave in many ways. However, here are several areas where I've found differences worth attention.

(Please note these observations are based on experiences that are, in some cases, now several months old. Please submit a comment and let me know which observations I can update.)

1. Ease of use (front and back end)

Overall, WordPress MU's interface is pretty intuitive, in both the "front-end" (what the public sees) and the "back-end" (what the administrator sees). WPMU ships with a highly-integrated (and configurable) visual editor right out of the box — and it generates valid XHTML code — whereas, for Drupal, visual editors are add-on modules. The optimization for search engines and the variety of navigation plug-ins for WPMU are extensive.

In Drupal, the permeable boundary between administration and presentation seems like a good approach. When you're logged in as an administrator, you see the same screen as other users with several additional navigation elements for administering the site.

However, after configuring several instances, it became harder for me to keep track of the public and the private, especially when I started integrating Blocks and Views into Books, Pages, and Stories. Although a contributed Drupal plug-in can allow you to take the role of another user, that was an extra step. On the other hand, WordPress MU kept the public and administration areas separate, and I found that approach easier to keep straight in my mind.

2. Managing and administering multiple sites

I have not administered completely separate sites with Drupal since version 6 stabilized. Prior to that point, Drupal worked best for me as one large ecosystem, with organic groups available for subsites, and the best option for multiple sites was to use separate instances. I know there are multisite modules and procedures, but haven't tried them. Are multiple sites now easier to manageout of the box?

WordPress MU refined the interface for multiple subsites ... this is what it was actually built for. The approach is to make global themes available (with site-specific styling) and plugins, while providing a separate back-end for the editors for each site. I look forward to seeing how the single and multiple user versions of WordPress are integrated in version 3.

3. Extensibility and dependability of add-ons

With both packages, the core software is highly usable, but user-contributed add-ons are required for the kind of functions we need. With Drupal there has been a lag time between core releases and the release of those important add-ons — with version 6, some of the critical modules I needed were not upgraded for as long as 6 months. I know improving this record is a priority for Drupal 7.

With WPMU, I've been paying close attention to plugin updates (and the new user rating service: "this works/this is broken") to evaluate the sustainability of multiple plugins which might provide similar functions. I've been able to apply updates within a day or two of their release.

4. Integrating enterprise data

Displaying enterprise data — such as course listings and directory information — has been the greatest challenge in site architecture prototyping. Both software packages provide support for collections of custom fields, but what's important is determining the best repository for each type of data and how to present it on public-facing Web sites.

With Drupal, my students and I developed a number of different data/content types (many of those types live on in our DabbleDB prototype). Unfortunately, managing these many data structures in one service was ideal, but the actual effort administering the system was high, keeping track of permissions and relationships (for what was relatively simple data collections). Also, at one point, some random change to the database hosed a number of my content types and I didn't know until quite some time later, when I returned to that portion of the site.

However, when I looked at the actual sets of data to be shared (rather than an ideal architecture), I discovered some needed to be managed within the content platform and some needed to be pulled from enterprise sources via RSS or microformatted HTML snippets. This simplifies the management of enterprise data. Both handle data type support, with Drupal support being more integrated into the core software and, in WordPress MU, more through plugins.

5. Ease of deploying emergency site

The ability to rapidly deploy and manage Web communications during an emergency has finally gotten recognition over the past  year of two, following high-profile campus emergencies. I've seen several approaches tried, from creating a parallel home site with static page caching, to developing an emergency site which is hosted off campus and available through an alternative domain service.

Why not do both? Why not apply static-page caching to Drupal and WordPress, and also use a generic hosting environment which would allow fast migration to external hosts in an emergency? This would seem possible with both software packages, although my most recent experience is with external hosting services for WordPress and WordPress MU.

6. In the end...

What it comes down to in the end, though, is the intuitive experience of authoring, editing, and managing each package. Have you used both?

What do you think?

Resources

• College Web Editor: Why use WordPress for the online version of your college magazine? (January 2010)
• Slate: Running the White House Web site on Drupal (October 2009)
• MIT World: The State of Drupal (October 2009)
  
• College Web Editor: Duke gets a new homepage powered by Drupal and… campus stories (October 2009)
• College Web Editor: Swarthmore College runs the online version of its magazine on WordPress (October 2009)
• WordPress TV: State of the Word (June 2008)
  
• SxSW: A comparison of WordPress and Drupal (May 2009)
• Good Web Practices: Wordpress vs Joomla vs Drupal (March 2009)
• Idealware: Comparing Open Source Content Management Systems: WordPress, Joomla, Drupal, and Plone (November 2008)
• New Local Media: CMS Comparison of Joomla 1.5, Drupal 6, and Wordpress 2 (September 2008)

[Updated: Added to resources list.]

Related posts:

1. Moving into the Hub After two years blogging at batesmedia.net, I have moved to...
2. Home/Views status report Vice President of College Advancement Kelly Kerner sponsored Home 4...

Related posts brought to you by Yet Another Related Posts Plugin.