WordPress Versions

WordPress Vs Drupal

If you're a regular reader of my site then you will know that I do a lot of development with WordPress, this being the most popular CMS it seems like a good choice of software to learn. But lately I've been trying to learn the second largest CMS...Drupal, what you first hear about Drupal is the steep learning curve that you must go through to understand how Drupal works.

This article is going to go through my learning curve of Drupal and of course comparing it with WordPress and let you know my opinion of both these CMS's. I know people will be expecting me to say WordPress is a better CMS so I'm going to try to keep this as unbiased as I possible can. Some of the things we are going to cover are:

Content Types

WordPress

custom_post_type

By default WordPress comes installed with 2 content types, things are either a post or a page. The way WordPress works with content is on a page by page basis. You create your page and enter the content in the content editor. WordPress has now created a new page for this one single piece of content which you can view on it's own page. You can assign multiple types of content to a single page by using custom post meta data. This will allow you to have extra content fields for your page, for example if you were selling a product you will have a product description area plus content fields for the price, quantity etc.

If you want to enter content that is neither a post or a page then WordPress allows you to create new custom post type but using the function register_post_type().

function codex_custom_init() {
    $args = array( 'public' => true, 'label' => 'Books' );
    register_post_type( 'book', $args );
}
add_action( 'init', 'codex_custom_init' );

If the content authors would like to create a new custom post type then this is something they will need to contact a developer about doing.

Drupal

The content in Drupal is managed in a similar way, they are defined as nodes...a Drupal node is made up of a content type which can have multiple content fields. All the content fields and content types can be managed in the admin area, so the content author will not need to contact a developer to make changes for different content types. When you create a new content type you then have the option to change as many content fields are you want, you can even select the type of field it is, you can use textboxes, select boxes, checkboxes etc.

drupal-content-type

After you have created the content type you can now create a node based on this content type. Just enter the information in the content fields and when you save, it will create a node page with your content. Each new node will have it's own page and own Drupal path to get to this content, the URL is used as an alias for the Drupal path.

URL Structure

WordPress

The URL structure your pages use in WordPress are defined by changing the settings under Settings -> Permalinks this allows you use certain tokens in the URL. You can even change the URL on the individual page by changing the edit.

Permalinks

Drupal

The way Drupal deals with URL structure is completely different, first each piece of content has what is known as a Drupal path. This is a path that can access the node, when you change the URL it will get the content by linking the URL to the Drupal Path. If you add a new node the Drupal path for that node will be domain.com/node/123, with 123 being the node ID.

On each piece of content you can define a default pattern for it to use, so you can say if this is the product content type then the URL will be /%category%/%product-name%. This is only set as the default if you want to change this after you can do so by editing the node.

drupal-url

Themes

WordPress

With WordPress you need to create all the HTML for each theme, unless you use a child theme. You have the ability to create a child theme but it is not a child theme by default. The theme is broken up into different page types, index page, category pages, single page, taxonomy pages etc.

Manage Themes ‹ Dev WordPress — WordPress

There is a template hierarchy of pages so that if you want to display a specific single page and single page template files haven't been created then WordPress will use the index page template file to display the content.

Drupal

All themes in Drupal are child themes, when you create a new theme you don’t need to have any template files and you will still have default HTML to use in the theme. The theme is broken down into a number of different areas, HTML, page, regions, nodes and blocks. Each of these theme files will be used on all pages of the website but depending on the content they could look different.

For this reason it makes Drupal theme development easier to start off as you don't need any template files and your theme will display your content, if you're first starting out with Drupal development it can be quite difficult to work out what theme file is displaying what HTML, is it in your theme files or is it the default files that your theme uses as a parent theme.

WordPress makes this a bit easier to control what HTML is output, as you write the only HTML that will appear. If you don't have a single.php file then you know WordPress will get the HTML from the index.php file, this should make WordPress theme easier to maintain.

drupal-themes

WordPress

Adding features such as menus is about the same on both CMS's, in WordPress you use the function wp_nav() to display a menu and WordPress will generate the HTML for you and all the links to the pages. WordPress comes with a drag and drop menu screen which makes it easier to select the hierarchy of the menu you are creating.

You can create as many menus as you like and choose where to display these in your theme by using navigation locations in your theme files.

Wordpress menu

Drupal

In Drupal you use a theme function theme('links__system_main_menu', $options) to display the main navigation for the website. Both CMS's allow you to customise this in the admin area making it very easy to select what links to use.

Drupal allows you to customise the menus in both the front-end and the admin area so you can create your own menu and your own shortcuts to links. For authors this can be very useful as you get to pick how you best want to work with the CMS. But for developers it doesn't make much difference as WordPress makes it easy to customise the menu items you see. If you want to do this in WordPress here is a useful plugin to use Controlling The WordPress Toolbar.

menu-screen

WordPress

WordPress uses Widgets and widgetized areas, within your theme. A widget is a piece of PHP code that the user can position in a place on the theme to display this code. For example if you have a sidebar on your website and want to display your social icons, newsletter signup form and favourite links, these will be widgets in WordPress where you can drag into the sidebar of your site.

This feature is really useful for customising content on your site, but this is also the biggest area that WordPress falls behind of Drupal. In WordPress you define your widgets and they are the same throughout your site, you can't turn them off on certain pages or add additional widgets on certain pages. Content for the widgets are fixed to the settings you define on the widget page. For me this is worst part of working with WordPress and is a feature which I really hope improves in the future.

688px-widget-panel

Drupal

As mentioned above there are a few things missing in WordPress widget feature that exist in Drupal. With Drupal you have widgetized areas but they are called regions, and widgets are called blocks. You can assign blocks to any of the regions, you can also go into the settings of the block and only make it appear on a certain content types or make it so the block isn't displayed on a certain page.

You have full control on where the blocks on displayed on your website.

blocks-screen

User Management

WordPress

WordPress has an inbuilt user management system, which comes with a number of default roles, each have their own level of capabilities to do varies tasks within the CMS. As the Admin user you have the ability to change the role of any user created by the CMS.

You do not have the ability within the CMS to create new roles and give them different capabilities, but this can easily be done by a developer in the code by using a couple of lines.

Handling WordPress User Roles

Drupal

In the CMS Drupal gives you more control over the permissions you give to each user. Just like WordPress you assign users different roles and these have different capabilities to perform a number of tasks. But Drupal has a user called Anonymous which is given to anyone using the site that isn't logged in and you can assign different permissions to this user straight from the CMS.

The Admin user has to create their own roles and assign permissions to all the different roles, this means that they have more control over the permissions but it will take more time to setup. But developers don't need to get involved in assigning permissions to different things as the admin user can do this themselves.

When you install a new module this will be added to the permission screen so you can define what the different users can do with this plugin.

people-screen

Taxonomies

WordPress

WordPress comes by default with two types of taxonomies attached to the posts post type, these are categories and tags. Categories are in a hierarchy and are pre-defined. A post can be assign to multiple categories and they're a great way to group different posts together. Because they come in a hierarchy it allows you to have parent categories which makes it easy to organise your pages.

Categories

Tags give you more freedom than categories you can add new tags easily by typing them in the tags textbox on the post screen.

In a normal website having just categories and tags is enough functionality to group your posts, but WordPress is a CMS and can be used to create custom post types. These new post types might not fit into the previous taxonomies you have, so you might have to create a new custom taxonomy to allow you to group your new post types.

Since WordPress 2.3 developers have been able to create their own custom taxonomies, which can either have a hierarchy like categories or have a single level like tags.

Both are used to group content together categories are for hierarchy groups while tags are used to label the post.

Drupal

Drupal taxonomies are very similar to what you can get in WordPress you can choose between categories or tags. You can create as many categories as you want and can add all the terms inside the category.

These categories can be used as content fields to choose the category for this node. You can define any category to use inside a node, or you can assign a node to a tag. When you use tags in Drupal you can use the autocomplete field to help content authors assign the correct tags to the different nodes.

taxonomy-screen

Plugins / Modules

Being able to extend the functionality of the different CMS's is the main reason behind the growth of both CMS's, there are loads of ways you can extend the functionality but they do it in different ways.

WordPress

In WordPress to extend the functionality you would create a plugin, this plugin will be populated with functions to run at certain points in the code. These points in the code are known as hooks and filters. When you assign a function to run on a hook WordPress will queue up a number of functions to run at this point in the code.

A hook is a way of changing the functionality or extending the functionality at a certain point in time. A filter is a way of processing data you get back at a certain event.

For example a hook will be used to run another function when a new user has been added to the system, and a filter will be used to change the content you get from the database.

install-plugin

There are already 1000s of plugins to use for free in WordPress which you can get to from the plugin repository.

Plugin Repository

Drupal

To extend the functionality in Drupal you can also create custom code to run at certain points in the application by using hooks. These hooks will sit in Drupal modules which is Drupals version of plugins. Drupal modules also have a feature of module dependency so you can create your modules and make sure that other modules are installed before you use yours. This is a really useful feature if you are working with API's that need to use oAuth connections, you can make sure that you have the oAuth module before you can use your module.

Modules - drupal.org

There are 1000s of hooks that you can use in Drupal these can be used to change the content, change menus, add config pages, change forms, change submit actions, anything you would want to customise there is most likely a hook for this.

Drupal is a bit more flexible with how it runs it's hooks. In WordPress an action will only run on code where there is a do_action() or a apply_filter() function. So if these functions aren't in the code you want to change then you can't edit this area of WordPress.

This is where I believe Drupal gives you much more flexibility in extending the core code. An example of this is changing an inbuilt form in WordPress can't be done unless there is a filter, but most WordPress admin area forms are hardcoded HTML so you can't add or remove extra fields in the form. This is different in Drupal as each form will have a pre hook by using the form ID, therefore any form added by the core code can be changed by using this form hook.

Unit Testing

WordPress

The WordPress core code is unit tested by the development team but there isn't an in-built framework for unit testing. The way that you would unit test plugins and themes in WordPress is to install the unit test core WordPress code http://unit-tests.svn.wordpress.org/trunk and run the plugin with PHPunit installed.

To learn more about unit testing with WordPress Tom McFarlin has wrote a tutorial series for WPTuts.

The Beginner’s Guide to Unit Testing: What Is Unit Testing?

Drupal

Drupal testing focuses more on functional testing rather than unit testing, this is because you can use the Drupal test database to run your tests. Rather than using unit testing you aren't dependent on certain data to be in place before you can run your testing. Because of the way Drupal is written functional testing becomes more affective as you can see how your code will interact with the database. Drupal comes with a built-in framework called simpletest you will use to test your modules.

When running tests in Drupal it will create a new instance on Drupal on each test therefore anything the test does will not affect the database used on your site. The benefit of creating a new instance to run the tests is that on completion of the test Drupal can just delete this instance of the test and your site runs as normal.

Tests can be ran directly in the admin area by navigating to admin/config/development/testing, here you can run all tests assigned to a module or just a specific test.

To learn more about Drupal unit tests on Drupal documentation.

Drupal unit Test

Auto upgrade

As both of these are open source code you will get updates of the core code a couple of times a year, these will either be security updates or new features.

WordPress

In WordPress when there is a new update you get alerted at the top of the screen that there is a new update and that you need to update WordPress now. You are given a link to go to the upgrade page, WordPress will then display your maintenance screen and start the automatic upgrade of the core code. It makes any database changes for you and automatically changes any core files that it needs to.

This is also the same for themes and plugins, WordPress will do automatic checks against the version number on the repository and the current version of the plugin and theme. If there is a new version available then WordPress will notify the user in the admin area that there is a new version available. The admin user can then log into the admin area and update the theme or plugin directly in the admin area.

Drupal

By default Drupal does not have an auto update from the admin area, it will let you know that there are new releases for the modules/themes/core code but this change will need to be downloaded and patched into the existing site. This means that it's only ideal ran by the developer of the site as they can make sure this is uploaded correctly.

Code Source / OOP

Both of the code sources are actually quite similar both are developed by making use of hooks in the code to add addition functionality. Both code sources were started around the same time when PHP was mainly procedural code, therefore some of the core code is still mainly procedural code. Both systems are moving some of the code over to object oriented programming but this isn't everywhere, but it's always best to check the documentation on how to use the different functions.

Drupal Documentation

WordPress Codex

File System / Media System

WordPress

640px-managefiles The WordPress media library is accessed from the admin area from the main menu, here you will be able to see all of the images or media files that have been uploaded into WordPress. When you upload a file in WordPress it will automatically resize the image to the defined sizes in Settings -> Media.

On each post in WordPress there is an add media button which allows you to insert your media files into the post, when you add the image to a post you can choose one of these sizes to use.

Drupal

media_content_tab

Users with the Edit media permission are given access to another tab titled Media on the content administration page. Selecting this tab will bring up a page listing all the media that has been uploaded to the site. When a file is uploaded into Drupal it will also resize the image to predefined sizes so you have the option of different sizes in the CMS.

Defining the 404 page

WordPress

In WordPress the 404 page is defined in the theme files by creating a file of 404.php, these are styled in the theme files or content can be added by changing the file itself or by creating sidebar for the 404 page and add widgets to this page.

Drupal

In Drupal this is done in the admin area you can select a URL to display on a 404 error, the benefit to this is that the 404 page can be constructed just like any other page in the website, content nodes can be added and different blocks can be added to the page regions.

Multisite

WordPress

WordPress by default comes as a single site but by adding options to the wp-config.php file you quickly turn on the multisite feature which allows you to use a single instance of WordPress to host as many different sites as you want.

You can choose to have your website as sub-folders of your main site or as sub-domains, both will perform the same way. When new sites are created you can switch to these sites in the admin area and just manage these sites one at a time.

With WordPress multisite you can even share themes and plugin so you can make your sites look and function the same way, this makes it perfect to use for a network of websites.

Drupal

Drupal also has the ability to use a multisite feature, you are also able to share module and themes. Within the module and themes folder there are site specific folders and an all folder. Putting modules and themes inside this all folder will allow all sites to have access to this code, if you want a module to be used for a single site then make sure you add the module or theme inside the site specific folder.

The setup process in Drupal isn't as easy as it is in WordPress but the end result is the same, you can customise the URLs for each of your sites and switch between the sites to manage the different content.

Deployment

WordPress

The way the WordPress works means that most of the site setup is done in the code, for example custom taxonomies, custom post types or extending the functionality that the users have access to is done in code. When the users have access to these areas they can then configure the site to how they want it.

Because the main site changes are done in code this makes deployments very easy, all you have to do is upload the new plugin/code and you will have access to the new feature and the site will function exactly the same as on your development environment. There are very few times when you need to upload database changes with a deployment, the only database changes you will need to do is adding data to custom tables.

Drupal

I have found that deployments with Drupal aren't as straight forward as they are in WordPress because the site setup is done more in the admin area than in code this means that any changes you do in the development site you will have to replicate on the live site. All new custom taxonomies or custom post types are created in the admin area, even views for these new pages are created in the admin area.

Any changes that are just code are easy to deploy to the live site as you will just need to upload the new code and enable the module. But most of the time any changes that the user wants will need to be done in the admin area. If the client wants to see these changes before they go onto the live site you will need to make these changes on development and replicate this exactly on the live site.

Another option is to stop all content being added to the live site, take a backup and add this to your development site, make the changes in development, copy this database to live and then switch to this new database. All do able options but not as straight forward as having the site setup settings all in code as the deployment is simple.

Conclusion

My conclusion of both the CMS’s is that they are actually very similar, I've worked with WordPress for a while and understand what best applications you can create with it. I thought that Drupal gave you more control over the content and easier to big larger applications on. But after using both the CMS's my understanding is that they are very similar just deal with things in different ways.

Drupal out of the box has more features to it and it seems that most of the areas of customisation can be located in the admin area. WordPress has the ability to create these same features but they are customised via code added with a plugin or in the functions.php.

A basic example of this is JPEG image compression, in Drupal you do it in the admin area where in WordPress you do it in the code.

Drupal seems to be a better fit for an ever changing website, where you need a theme and not too sure what the final result will be so you want as much flexibility in the admin area as possible. Where WordPress seems to be able to focus on a certain type of website and do this well. Any changes to the website design or functionality will need to be done by a developer where Drupal feels like your be able to customise it more without a developer. But the View customization in Drupal can be confusing to your average user and I've been told that they prefer developers to make these changes. So it's an easy way for developers to make changes without writing code.

But is this always a good thing?

Should you allow content authors to control the website like this or should they have to report back to a developer for changes to design?

If you are a business without an inbuilt web development team then maybe Drupal will be the better choice for you, because with a bit of training you can fully customise everything in the admin area and even create new content types.

But with the features that Drupal can do in the admin area, WordPress can do in the code or there is probably a WordPress plugin that will do it for you. There certainly is a WordPress plugin that will allow you to create custom post types in the admin area.

I feel that Drupal gives you full control in the admin area for things that should be code, an example is creating custom taxonomies or post types, this should be in code, as deployments and changes from development to live environments are easier. If you do this in the admin area on your dev environment to create new template changes then when you deploy the templates you also need to make these admin area changes on the live website.

My personal favourite CMS is still WordPress mainly because I believe it's easier to learn and behaves as more of a code framework with a CMS that you can build on. I think WordPress customisation has come a long way in the past couple of years and can't think of a website that will be more suitable to be in Drupal than it would be to use WordPress.

The biggest reason I still use WordPress is for the end user, after building sites in both Drupal and WordPress, end users have commented on how easy WordPress is to use, while sites built in Drupal users have complained about how illogical the admin area is and how hard it is to find what they need to do. Yes the end user can have full control to make changes in the admin area but most of them don't want to as they are scared to make big changes to the site, so they end up contacting the developer to make these changes in the admin area.

This is the reason why I will continue to choose WordPress for creating websites that need a CMS.

Back to top

Fastest WordPress Hosting With WPEngine

Stunning speed, powerful security, and best-in-class customer service. At WP Engine.

Risk free for 60 days