Both Drupal and WordPress are open-source database-backed content management systems (CMSs) that can be used to deploy web sites and web applications. Some people feel very strongly that Drupal should be used for all web site projects, and others feel equally strongly that WordPress should be. My feeling is that while in principle, probably any web project could be built on either CMS, both WordPress and Drupal have their strengths and weaknesses, and each is better suited for certain types of web projects. In this article, I explore the similarities and differences between WordPress and Drupal, and discuss which types of web site projects I think are best suited for each CMS.
Executive summary of conclusions: WordPress is much easier to set up and use than Drupal, so if your web site fits the WordPress model (which you can read about below), I recommend that you use WordPress. However, Drupal is much more flexible than WordPress, so if your project falls outside of what WordPress is set up to do, I recommend using Drupal.
To understand this article fully, you should be reasonably familiar with the Internet and common features of web sites, be comfortable using a web browser, and have a background-level knowledge of web technologies in general (if you do not know much about web technologies, you might want to read the Which Web Technology Does What? article on this site). Hopefully, the information in the article will be useful to anyone needing to make a decision on which CMS to use, no matter their level of technical expertise.
Overview of WordPress and Drupal
Let's start with a brief overview of WordPress and Drupal. Both Drupal and WordPress are content management systems (CMSs) for web sites, which means that they give you the ability to create, edit, classify, and manage your site's content (the text, images, etc. on your site's pages) with a web-based interface. In addition, both WordPress and Drupal keep track of revisions of your content, which allows you to look at (and revert to) previous versions of your content, if you made a change by mistake.
The way this works is that your content is stored in a database; both WordPress and Drupal are normally deployed using MySQL as the database, though Drupal also supports the PostgreSQL database. The scripts that let you manage your content, for both WordPress and Drupal, are written in the PHP web scripting language. Both WordPress and Drupal are best hosted on a LAMP stack (Linux, Apache web server, MySQL, and PHP), though both will work adequately on a Windows/IIS platform (you still will need PHP and MySQL).
Both Drupal and WordPress are extensible web application platforms. You can create, download, and install themes for both CMSs, which define the look of your site (text color, fonts, layout, and how content is displayed). You can also create, download, and install plugins for WordPress and modules for Drupal, which add new functionality to your site.
The rest of this article goes into more depth about ease of use, content types, users and permissions, URL handling, and web site features in WordPress and Drupal, and how these factors might affect your decision of which CMS to use for a particular web site project.
Ease of Use
WordPress and Drupal are equally easy to install on a suitable web host: download a free software package, unzip it on your web host, create an empty database and a database user, tell the software about the database, and the CMS pretty much does the rest. Then you'll need to choose and install a theme for either system, which is also pretty easy to do; if you want to create a completely customized theme for either WordPress or Drupal, you'll find that to be about the same level of difficulty for either CMS.
After installing WordPress and making a few easy-to-understand configuration choices, it's pretty much ready to use. Drupal, on the other hand, usually requires a significant amount of additional configuration and module installation before it's ready to use for a typical web site.
WordPress and Drupal also differ greatly in how easy they are to understand. Even people with a minimal amount of technical knowledge usually find WordPress relatively intuitive. Drupal, on the other hand, has so many capabilities that it is much more difficult to figure out, unless someone has customized it to the point of getting rid of or hiding most of the confusing aspects (this is possible to do, but requires significant effort).
The flip side of ease of use is flexibility, however: WordPress is easy to use because it is set up to do particular tasks, and to some extent, Drupal is less intuitive because it is task-agnostic: Drupal has many capabilities and hasn't been set up to make any particular task easy. The following sections explore this aspect of flexibility in more detail, but let me just say now that if you are doing a project that does not require the flexibility of Drupal, I recommend choosing WordPress, because it is a lot easier to figure out and use.
Content Types, Taxonomy, and Fields
In this section, we'll look at several aspects of content types in Drupal and WordPress, and see how each CMS has advantages and disadvantages in this area for different web projects. Both Drupal and WordPress classify your site's content by type -- when you create content for your site, you have to start by choosing a content type. Each content type has different characteristics, and content from the different content types can be used and presented differently on your site.
WordPress has two content types built into its core: "post", which is for blog posts, news articles, and other date-sensitive content; and "page", which is for "static" (not date-related) content, such as the "About Us" page on a web site. WordPress plugins can define new content types, and this feature should be even better in WordPress 3.0 (though I haven't personally tried it).
Drupal's content type system is more flexible, as Drupal has the idea of multiple user-defined content types built into its core. When you install Drupal, you will have two content types defined: "story" (similar to WordPress's post) and "page" (similar to WordPress's page). You can also define your own content types from the administrative interface, and if you turn on some of the optional modules that come with Drupal, you can enable content types for blogs, polls, books, etc. Also, it is very straightforward to create modules for Drupal that define new content types, so there are many available modules that do so.
Both WordPress and Drupal offer taxonomy systems that you can use to classify your content. WordPress comes with two taxonomy systems for posts: categories, which are hierarchical (categories, sub-categories, sub-sub-categories, etc.), and tags, which are non-hierarchical. WordPress also comes with two methods for displaying lists of taxonomy: nested hierarchical lists and "clouds". One post can be put into multiple categories, and tagged with multiple tags (i.e. both taxonomies are multiple-valued); each post must have at least one category, but tags are not required on each post. WordPress's taxonomy system has recently been made more extensible: As of WordPress 2.8, it takes only 1 line of PHP code for a plugin to define a custom taxonomy system, at which point WordPress will automatically create the user interface for managing it and assigning taxonomy to posts or pages.
Drupal's Taxonomy system is even more flexible. From the administration interface of Drupal (with no additional modules), you can define as many hierarchical or flat taxonomy systems as you like, with different properties (you can make them required or not required, and either single-valued or multiple-valued). Each taxonomy system you define can also be assigned to as many content types as you like. However, if you want to make a list-based or cloud-based presentation of a Drupal taxonomy system, you will need to download and install an add-on module.
Another aspect of content that is commonly needed on web sites is fields. Both WordPress and Drupal let you enter, for each piece of content on your site, several characteristics that could be considered fields: a title, the body, an excerpt (shortened version of content used in some presentation modes), the author, the status (such as draft or published), and the publication date/time.
Beyond this set of standard fields, you might need to define custom fields for your content. For example, a site that listed schools might need its school listings to have fields for the location, grade levels, student to teacher ratio, tuition, and other characteristics. Furthermore, on such a site, you would probably want to add structured searching capability, to let your site visitors search by these characteristics to find a school that fits their needs.
In WordPress, one method for having custom fields is to use the taxonomy system, but this would not work well for numeric fields, date fields, or fields that always have unique values (such as addresses). WordPress also lets you add ad-hoc custom fields to a post or page, but the fields are somewhat difficult to display in your theme and because adding them is ad hoc, you cannot easily use this functionality to define a content type with a fixed set of fields. So, you'd probably want to create a plugin to add the custom fields you want to posts or pages and take care of the display issues; however, structured searching would be difficult to implement.
Drupal, on the other hand, has a standard module (the CCK add-on for Drupal 6 and earlier; included in the main Drupal distribution as Fields in Drupal 7) that allows you to define a fixed field structure for each content type on your site from the administration interface. Drupal also has several options for setting up structured searching (see my article on search options in Drupal for more information).
Because of all of these differences in how content types are defined and managed in Drupal and WordPress, I don't recommend using WordPress unless the content on your site fits neatly within WordPress's posts, pages, categories, and tags model (perhaps with a few extra custom taxonomies, now that this has been made easier). If the site you are planning has a need for multiple content types (i.e. you need to use and present content in multiple different ways) if you need to have custom field structures on your content types, or if you need structured searching, I recommend using Drupal.
Users, Roles, and Permissions
Drupal and WordPress have similar systems for managing users, assigning them to roles on the site, and granting each role permission to do certain actions on the site. Drupal has admin screens for this functionality by default; if you need to do role/permission management in WordPress, you'll need to install the Role Manager plugin, which works very well. I believe there are also plugins/modules for both systems that will allow you to define permissions on a post-by-post basis (I haven't tried the WordPress plugins, but the Drupal ones work well). Since the capabilities in this area are so similar, I don't see a strong reason to choose one CMS over the other on the basis of user, role, and permission management.
URL Handling
In this section, we'll look at how differences in the handling of URLs in Drupal and WordPress can affect your decision of which CMS to choose for your web projects.
When you visit a URL within a Drupal or WordPress site, the software has to decide what content is being asked for, find this content in the database, pass the content to the theme to convert it into an HTML page, and then send the resulting HTML page to your browser. But although both CMSs follow this same general outline of steps, there are some fundamental differences.
Basically, WordPress has at its core the idea that a particular URL represents a list of one or more pages or posts (or a 404 error if the list is empty). So, when presented with a URL, WordPress is always trying to convert it into a database query whose result is a list of one or more pages or posts. For instance, a URL like http://example.com/category/garden would give you a list of all the posts in the "garden" category, and http://example.com/about would give you just the "About" page. WordPress includes URL structures for taxonomy (categories and tags), authors, individual posts, date-based archives, and keyword searches, and plugins can add additional ways to translate URLs into queries (though this is quite complex). Plugins can also completely override WordPress's query system for particular URLs that they intercept, basically by taking over page generation from the core of WordPress before the query kicks in.
Drupal has at its core a completely different and flexible idea for URLs: Any module can register for a URL within the site, and when this URL is requested, Drupal basically asks the module to decide what to display on the page, which need not be a list of content. So, while some modules define query-driven URLs similar to WordPress, other URLs can have completely different behavior, such as displaying an administrative screen or a Flash application.
Because of this fundamental difference in how URLs are treated, WordPress is better than Drupal for sites that fit its particular blog-based model of "find a list of posts or pages, based on the URL, and display them", because using Drupal to set up the URL logic that WordPress has at its core would be difficult. However, if your web project involves a URL and page structure that doesn't fit within WordPress's model, or if you don't want some of the URL-query connections that WordPress defines, you'll be a lot better off trying to build your site in Drupal, which has the flexibility to handle whatever URL structure you want to define.
Features/Functionality
Today's web sites offer many features and functionality areas beyond just displaying images and text on web pages. WordPress and Drupal differ greatly in the features/functionality they make easy to deploy. So, in this section, we'll look at this aspect of choosing a CMS for your web site project.
One area of functionality that is commonly needed on web sites is the ability to make lists of content, such as date-based archives ("all the posts from January"), category-based archives ("all the posts in category x"), and field-based search results lists ("all the schools with tuition under x"). As we saw in the previous sections, if your site needs the type of lists that WordPress knows how to use, WordPress does an excellent job of deploying them. But if you need other types of lists, such as structured searching, lists segregated by content type, or lists formatted in multiple ways, you will probably find them easier to generate in Drupal. In either CMS, the lists you generate can quite easily be delivered in RSS format as well as HTML pages.
Another area of functionality that is commonly used on web sites is the ability to add chunks of content to the page sidebar(s), such as a list of the most recent news items, your favorite web links, a tag cloud, a daily quotation, or an advertisement. Both Drupal and WordPress make this pretty easy to do, and there are many plugins/modules available for both systems that give you many options of things to add to your sidebars if the core functionality is not enough. WordPress offers many built-in "widgets" for sidebars: the types that are commonly used on blogs. Drupal calls its system "blocks", and has fewer built-in options; however, its system is slightly more flexible, in that you can specify which pages which blocks should appear on; put the blocks in other areas such as header, footer, and content pane; and restrict viewing of certain blocks to certain classes of users. So, if you need this type of flexibility, Drupal would be a better choice; if you don't, then either CMS should be fine, and WordPress will have more options by default.
There are many other features that your web site might need, such as contact forms, polls, per-user blogs, customized user profiles, forums, event calendars, event sign-ups, e-commerce, the ability for members to send messages to each other, etc. Some of these features can be added to WordPress by installing a plugin, but my general feeling is that if your site needs features that go much beyond the built-in abilities of WordPress, as outlined in the "Content Types" and "URL Handling" sections above, you are probably better off with Drupal. I have several reasons for saying that:
- From a programmer's perspective, Drupal is really built for adding new features, whereas that concept is somewhat of an override or "hack" in WordPress.
- Major functionality plugins I've tried for WordPress tend to be less reliable than major functionality modules I've tried for Drupal.
- Plugins and modules often break when a new major version of the software comes out. WordPress releases a new major version every few months, and the WordPress team does not continue to support older versions with security updates and important bug fixes, so you really do need to update to each new version. Drupal's schedule is to have a major release every few years, and at any time, they have two major releases supported with security updates and important bug fixes in "minor" releases; you can generally upgrade to a new minor version without breaking anything on your site. This means that your site should continue working, with security upgrades, for several years in Drupal, whereas you may have trouble in a couple of months with WordPress.
Conclusions
Hopefully, the preceding discussion has provided you with enough knowledge about Drupal and WordPress to decide which would be better for your web project. WordPress does certain things very well: it is pretty easy to set up and use, and I think it's a better choice than Drupal if your needs fit within its model of posts, pages, categories, tags, and sidebar widgets. On the other hand, Drupal is a much more flexible CMS, so if your project falls outside WordPress's model, I think that Drupal is a better choice. My recommendation is that you choose the right tool for your particular web project, rather than trying to make every project work in one specific CMS.
Once you have decided on WordPress or Drupal for your project, you may find some of the other articles on this site to be helpful. And if you need help completing your Drupal project, please contact Poplar ProductivityWare.