Drupal vs Wordpress - My experiences and impressions

vince's picture
I should have posted this earlier but never got around to it. It's not based on the latest version of Wordpress because these notes are from a few years ago when I was evaluating different CMS's to choose what to use for our web sites. I spent months researching, evaluating and testing a bunch of different CMS platforms for our web sites and it came down to Drupal and Wordpress as my top two runner ups.
Drupal logo
After spending a fair amount of time evaluating and using Drupal 7 and setting up a basic web site, I decided to give Wordpress 3.5.1 a fair and more complete evaluation before deciding to stay with Drupal.

So far, out of all the CMS's I have evaluated, I think I would rank Wordpress above all of them except Drupal. After working with Wordpress for at least several days, I think, overall, it is a pretty nice CMS for blogs and simple sites. However, I have come to the conclusion that, as others are saying, for anything beyond that, Drupal is far better suited.

They say Wordpress is lighter weight than Drupal. However, out of the box, Drupal-7.22 is 7.85MB and Wordpress-3.5.1 is 9MB. So Wordpress is actually bigger. Like they say, Wordpress does create a lot fewer database tables thanWordpress logo Drupal, but so far, I am not seeing a notable performance impact because of it.

Out of the box, Wordpress is simpler to get started with for a new user. It has a WYSIWYG editor, and the ability to schedule the date/time of content publishing, for example. In Drupal, I had to research and choose a wysiwyg editor module and install a few other modules for similar features. However, Drupal has other powerful features out of the box that Wordpress does not have, such as extensive user management with content publishing access controls, a check box to control whether to provide a menu link for content, control of whether content is promoted to the front page, full custom content type creation, etc.

They say Wordpress is so much more user friendly, and it seemed that way right at first. But after using it for a while, I'm not seeing it. For example Wordpress 3, they say, supports custom post types, Wordpress's answer to Drupals custom content types, out of the box. I looked everywhere in the backend and could not find it. Go to the documentation, http://codex.wordpress.org/Post_Types and the instructions are to write custom PHP code to create the post types, as apposed to Drupals out of the box interface, where you just go to Structure->content types, and click "Add content type" and create it through the GUI.

Now, granted, there are several plugins to provide a GUI for custom post types in Wordpress. However, it is interesting that Drupal already has all this in core, yet it is smaller than Wordpress. I didn't spend the time evaluating and choosing a custom content plugin because I chose to stay with Drupal because of some of the other features and issues, discussed below, to which I did not find a readily available solution.

Wordpress initially loads faster in the backend when neither have been accessed for a while. However, once I have loaded a couple of admin screens in Drupal, it speeds up and seems comparable to Wordpress. In my tests on fairly simple sites, the frontend page loading speed for unregistered users is just about the same in Wordpress and Drupal.

One thing I didn't like at all about Wordpress is that, out of the box, you could not copy a site, for example a development site, to another site with a different URL, because all URL's are absolute. So the whole site would break. After research, I finally found I had to install a module, to remap the URL's to all be relative and add some custom configuration to wp-config.php to make my sites relocatable. I saw posting after posting of people having the same problem. In fact, while I was working on figuring it out, another person on the #wordpress IRC was experiencing the same problem and asking how to fix it and getting no answers that solved the problem fully. I ended up helping him with it as I figured it out.

It was fixable, but this raised a red flag. Why would this not be the default behaviour, like it is in Drupal? How could the developers have a real world mindset for production web sites and not make Wordpress sites relocatable with relative URLs out of the box so that I can stage development sites to production?

There are a number of other limitations/issues with Wordpress that I didn't want to live with for anything other than a simple blog or static content site.

  • I cannot control postings from being posted on the front page in Wordpress. Either all posts get promoted to the front page, or none of them do. The closest there is to controlling it, so far as I know, is with a plugin called "Opt-In Front Page", but it is apparently based on category rather than individual selection. In Drupal, you have a check box for every page or article to promote to the front page, and the default can be set to on or off.

  • There does not seem to be a way to control what menus get displayed on what pages. Once you put a menu in a widget area for a theme, it always shows that menu. Unlike Drupal where you have full control of the menu block and can specify what pages or content types it displays on, what users can see it, etc.

    This is kind of a show stopper as we need, for example, software project pages and product pages that have their own menus or other content blocks that do not appear on other parts of the site.

  • Although more complex in some ways, I find the Drupal admin interface to be more consistent. For example, every theme I have tried in Drupal has a base set of settings for such things as the logo, etc., via the same interface. In Wordpress, every theme seems to have it's own admin interface that has no resemblance to each other. Each one feels like a completely separate application and a lot of themes do not even have the ability to set the logo through the GUI without modifying PHP code.

  • I find myself being directed to modify PHP code for simple settings or features in Wordpress, that are consistently and easily configurable via the GUI in Drupal. From that standpoint, even though Wordpress appears easier in the beginning, as you dig into creating web sites it no longer appears to be. For example: When trying to find a way to control article promotion to the front page on an individual article basis.

  • Drupal has a much more user friendly and powerful interface for managing what blocks are placed in what regions. For every theme, you can go into Blocks and click "demonstrate block regions" and you get a visual representation of the theme showing the location of every block. In Wordpress, you get no such visual representation. You just get the names of the blocks in a column where you drag widgets to the chosen block. You have to guess by the "widget area" name where it is going to be placed.

    In Wordpress you don't have any display controls for the widget either. Perhaps there are plugins to provide more controls. In Drupal, for every block, you can click the "configure" link and configure where and under what conditions the block is displayed - what pages, which content types, what roles, and what users can see it.

    In Wordpress you can also only configure widget placement for the current active theme. In Drupal, in the Blocks management screen, I have tabs at the top for each installed theme. I can just directly select the tab, and arrange the blocks the way I want an choose which ones are visible for that theme.

  • Although some of the Wordpress themes have a lot of content regions (widget areas), I am finding that, on the average, Drupal themes seem to have a lot more block regions to place content in than Wordpress themes do. A lot of Wordpress themes only have a small number of regions in the sidebars, like 1 or 2. I am guessing this is because of Wordpress's blog oriented mindset.

    Drupal themes on the other hand seem to almost always have regions not only in the sidebars, but also multiple regions in the header, footer, and main content areas. Two of the simplest themes I played with in Drupal, 'Aberdeen', has 7 regions, header, footer, both sidebars, and 3 regions in the center content area, and their default theme, "Garland", also has 7, including 3 regions in the main content area.

  • I am finding the Drupal admin interface to be more efficient. Although there are plugins for Wordpress, that I have not tested, for front end editing. In Drupal I don't seem to have to flip between front end and back end interface near as much. In the front end, every content block has a little gear, that appears when you hover over the region, with a drop down menu to edit, delete, configure access control, etc..

    In Wordpress, you only have access to a sub-set of the admin menus from the front end. I find myself always having to load the dashboard to gain access to the full menu then clicking the item I want to manage from the menu. Drupal has all administration sections available in the menu bar at the top at all times.

    Also, Drupal has a nice shortcuts bar at the top that you can customize to take you directly to any administration function that you use regularly. It works kind of like the bookmarks bar in your web browser. It is invaluable for efficiency.

  • The common consensus seems to be that Drupal is a lot more secure than Wordpress. Here is one example article.

    WordPress is notorious for being the least secure CMS. While this is definitely because it is the most popular CMS, and thus relatively easier to hack, it still cannot be denied that newer security loop-holes are discovered in WP way more often than in either Drupal or Joomla! Furthermore, WP plugins and themes too come with their share of hacks and exploits.
    Drupal, on the other hand, seems to be the most secure CMS of the three, with the least number of hacks and exploits, on an average (it was chosen by The White House for its website, after all).
For a more serious CMS where you are not likely to get cornered if your site becomes very complex, I have come to the conclusion that Drupal is, by far, the better choice.


At the time I wrote all the above notes, I hadn't even learned how to use Drupal's taxonomy features for categorizing content based on key words, and the views module yet. So far as I know, Drupal has no rival to these features. Now that I have more experience with Drupal, I am finding that views is infinitely powerful and flexible when it comes to dynamically generating menus, lists of content, teasers, photo galleries, just about anything from any content in your database. All easily configurable via the GUI interface without writing a single line of code. I have to admit, I find it quite cool.

Another very nice tool that Drupal has is drush, the Drupal Shell command line tool. This allows you to do a lot of administration tasks on your web sites from the shell command line. This allows advanced website management from scripts which is especially useful if you manage a number of web sites. I don't use anywhere near all it's features, but it has been very useful for clearing caches, updating the database tables after installing/upgrading modules, unblocking administratively blocked users, listing/enabling/disabling modules, taking sites in/out of maintenance mode, etc.

I have found no other CMS that has similar command line management capability.

Another thing to note is that the new Drupal 8 branch has removed some of the few barriers to new users. It now has WYSIWYG content editing out of the box for example. Also, some of the most useful features, such as the views module, that almost everybody ended up installing, is now in the core system. They also have added front end content editing features that are quite nice.

I haven't changed over to Drupal 8 yet because the last time I tested it some of the modules that I need were not working properly yet and the drush command line tool didn't work properly yet. I am looking forward to it though. It has been long enough that I need to re-visit it when I get a chance. I have noticed that the official Drupal web site has not changed to Drupal 8 yet either.