Collaborate, Create, Communicate

Choosing an Open Source CMS: the Ever-recurring Question of WordPress vs. Drupal

Updated 16 December, 2010
While my colleagues in IT are reading this post and, with mouths agape, thinking “WHAT, you giving a plug to Open Source CMS?”,  I still remain a hardcore champion of Enterprise Content Management (ECM) to suit the right needs and when the right resources and commitment are in place.  And so begins my plug for what I found to be a robust, scalable, usable and well-engineered Open Source CMS – WordPress.

Blogs and Wikis have revolutionized Web publishing, paving the way for wider adoption of their publishing tools and instilling simple publishing processes, hence changing the culture in organizations.

The problem is, when faced with the to CMS or not to CMS conundrum, IT managers are presented with the whole gamut of information management solutions (Web, document, digital asset, and so on), all of which promise Content Management. Just take a look at this “list of notable content management systems that are used to organize and facilitate collaborative content creation”, and you will see a variety of Open Source and proprietary solutions, supported technologies, portals, frameworks, and blogging platforms, as well as licensing models.

To quote my good friend and colleague in IT management, Tobias Carlander of World Food Programme, when evaluating and choosing solutions, “there is no silver bullet”.  Large organizations, both international public and private companies, often struggle with choosing information systems which can be a part of a heterogeneous IT landscape.  And so when evaluating IT solutions, IT managers must consider interoperability, sustainability, and alignment to strategic information and content management objectives among the highest priorities.


The release of the CGIAR Ongoing Research Web site is the result of an effort to both enrich and expand the exchange and reuse of the CGIAR agricultural project information, as well as support new views of agricultural research, as the new CGIAR research agenda unfolds and is put into action.

This effort required migrating the Ongoing Research Web site and editorial system from a Web application framework to a proper CMS in order to:

  1. provide scalability and sustainability for the future development/expansion of the system, even with regard to where it is hosted;
  2. improve user experience, for both visitors of the Web site and those who contribute to it;

    Notes about usability
    A usable Web site depends greatly on the efficiency of the Web site’s User Interface Structure [User Interface Structure – Web, Human Factors International] and therefore is not directly related to the choice of CMS, rather to how it is planned and implemented.  However, I certainly believe that a CMS can facilitate the implementation of a well-designed User Interface Structure by separating content from design/presentation (i.e., themes).

    Customized Editorial Interface
    Customized Editorial Interface: Catalogue Browse/Search

    A usable editorial interface (in our case, one where scientists and researchers voluntarily provide project information) can be greatly aided by a usable CMS.  Why? Because when customizing/extending beyond the basic blog or Web site, developers can take advantage of libraries and methodologies already in the CMS to deliver usable interfaces to extended functionalities.  Here is a good example of a usability testing report done on WordPress 2.7’s Administration (editorial) Interface.

  3. facilitate the reuse and syndication of content;
  4. better define the publication process (draft and preview of content, workflow);
  5. better manage users and roles, controlled taxonomies and master lists.

A Pragmatic Approach

After reading the latest literature on Open Source CMS and having consultations with Open Source CMS experts (thank you to Peter Casier of WFP and mastermind behind Blog Tips) and colleagues, I evaluated and investigated the core of three Open Source Content Management Systems (Drupal version 6.17, WordPress version 3.0, and Plone version 3.3.5) by downloading, installing, and configuring the systems.  I looked at each system’s core CMS functions (e.g., managing content and metadata and delivering it on a Web site).

The Selection

All three systems were easy to install and set-up as a basic CMS.

While Plone is quite beautiful from the pure developer point of view (I will not compare apples and oranges, that is general-purpose languages like java and python to server-side scripting languages like php), it does not really fit our express need to have a multitude of hosting options.  Also, Plone appears to be a framework in which one must build or attempt to install combinations of modules and other frameworks for developing the system beyond the basic hierarchical Web site.  Also, developing the system beyond the very basics requires a much higher skilled programmer.  It is quite similar to the implementation of a portal to manage Web content.  It should be mentioned that since my evaluation, Plone 4.0 was released and promises many new and important CMS functionalities.

There are no great differences between WordPress and Drupal with regards to hosting and scalability.  But when it comes to user experience, out of the box, WordPress wins hands down.  Note that Drupal 7 should correct and/or improve upon many of its challenges with usability.

After the initial evaluation of Drupal and WordPress, in order to make a final decision, I put the systems to the test by putting on my developer hat and building a few of the required functionalities (a migration data loader, invitations to contribute to the system, multi-authorship of projects, and querying projects for display in the interactive map interface).

The Final Evaluation


  • WordPress: custom plugins and modules are widely available and easily developed and deployed; APIs are offered and promote compatibility; it has a large community of both core and contributing developers;
  • Drupal: is developer friendly, but modules must be built ground up (vertically) and most time require dedicated development resources for obtaining an end-product;  vertical development in this fashion many times means that extending an information object (say for a future enhancement) would require developing at the core, creating a need for re-integration and consequently promoting a higher rate of bugs and incompatibility issues.


  • WordPress: upgrading the core is simple and safe (you always should back-up); updating/upgrading plugins and modules is simple;
  • Drupal: upgrading the core is quite a chore and many report that it requires clean installation then a subsequent migration; upgrading plugins or the core can cause instability, as there is no compatibility verification between the core or the APIs that the core exposes.


Both have a large number of hosting providers to choose from (Dreamhost, GoDaddy, Host Gator).


With the advent of version 3, WordPress can no longer be considered just a blogging platform. Version 3 improves on or adds several important CMS functionalities: custom post types (which should be called custom content types), custom taxonomies, and custom menu management. Add this to a system which provides a solid user-centered editorial interface and has the concept of Web publication at its core, and you have the recipe for a sound solution.

I developed the entire back-end and non-visual design front-end customizations of our WordPress CMS to satisfy requirements of the system.  This involved migrating content and users from the old system, extending taxonomies by linking them to master data, configuring custom content types, creating new user roles, making information required for publication, making master lists browsable and searchable in the editorial interface, and much more.

I used several plugins from the WordPress community of developers to extend roles and permissions.  I also developed two custom plugins to implement business rules for email notifications, required fields, Google Maps and Charts integration, and managing and linking to master data.

I only found one core issue with the system, which I reported on WordPress’ issues tracking system, and to my amazement a few hours later, WordPress core developer Andrew Nacin responded and had a patch ready for testing: they are serious, too.

WordPress vs. Drupal… really?

The problem with WordPress vs. Drupal is that the literature you read comparing the two can be misleading and quickly outdated.  So be careful when you read “The best solution is…”, and WordPress is good for blogs and simple sites but Drupal is good for complex Web sites, etc.  Technically, either of the two would have been able to fulfill our requirements.

My final thoughts on choosing an Open Source CMS:

  • no matter what literature you read comparing systems, keep in mind the goals and budget of your project, so as not to be sold on a system, yet convinced that it is the right one;
  • use a pragmatic approach to test out both what you have read and what your goals are;
  • don’t take for granted systems which offer solid user-centered design, as adoption is directly related to usability.

Did I make the right choice? Have you recently selected or evaluated a CMS, or are you planning to do so?  Please share your experiences and comments below!