Both Wordpress and Drupal are widely used and respected by a legion of developers. Wordpress is far more popular than Drupal, but Drupal is rapidly maturing with Version 8 looking likely to be a real serious contender that will breach the distance in takeup that is currently held by Wordpress.
Wordpress isn't a fully fledged CMS (I've avoided calling it as such in this article) but is a versatile blogging platform. This is not a criticism because that is what it is intended to be. Drupal, on the other hand, is a full-blown CMS that offers features in its core not found in Wordpress unless you add third-party plugins.
Image may be NSFW.
Clik here to view.
I've spend a lot of time developing for both platforms and this is my thoughts on their positive and negative sides.
This article is not a thorough review of both content platforms but is subjective opinion based on my experience. It would be interesting to hear the views of others who have experience of Drupal and Wordpress.
The APIs
The first thing of note if comparing the two is that their code is aimed at two different groups of users. Wordpress wants to allow non-professional developers to create themes and modules. Drupal was created and used by professional developers. This in itself lead to problems and the Drupal community has been engaging in a constant process of modifying and reviewing both the admin UX and the APIs to allow greater access beyond hardcore developers.
The downside of the Wordpress approach is that there isn't the strict coding rules and the myriad of inbuilt functions that is a feature of Drupal. This leaves open the possibility to sloppy written third-party addons which is less likely in Drupal because of their strict coding standards and its bigger API collection.
A lot of the Drupal API is really nice to work with, although the learning process is somewhat steeper than that of Wordpress. I think the form API is the best PHP form creation code I have ever used. The database API uses PDO so if you have knowledge of PHP Data Objects you'll find working with the Drupal database abstraction layer a smooth experience as they also use a lot of the same PDO methods like fetchAll() and fetchObject().
The Wordpress form API, called Settings, isn't to my liking. For those that are used to creating PHP / HTML forms on a regular basis, then the user interface of the Settings API is too far removed from the meat and bones of HTML forms. It is important to create a user interface that allows the creation of form elements in the structure that you would if you handcoded it.
This is an example of creating a form in Drupal:
$form['affiliate_hoover_unique_form'] = array(
'#type' => 'item',
'#description' => 'Some description here for form intro',
);
$form['first_part'] = array(
'#type' => 'fieldset',
'#title' => t('Feed details for '.arg(4)),
'#description' => 'Fieldset description here',
);
$form['first_part']['form_title'] = array(
'#type' => 'textfield',
'#title' => t('Title'),
'#required' => TRUE,
'#maxlength' => 255,
'#description' => t('Do not add anything other than the above codes for a title'),
'#default_value' => !empty($_REQUEST['form_title']) ? check_plain($_REQUEST['form_title']) :
check_plain($form_data->form_title),
);
$form['first_part']['form_body'] = array(
'#type' => 'textarea',
'#title' => t('Post body'),
'#required' => TRUE,
'#description' => t('You can use HTML in here. Examples:<br>To place an image: '.
htmlspecialchars("<img src="[#7#]">")."<br>To create a link: ".htmlspecialchars("<a href="[#5#]">[#1#]</a>").
'<br>If you are going to include internal links you must write the full URL, ie '.
htmlspecialchars("http://www.example.com/category/page-here")),
'#default_value' => !empty($_REQUEST['form_body']) ? $_REQUEST['form_body'] : $form_data->
form_body,
);
$form['first_part']['form_taxonomy'] = array(
'#type' => 'textfield',
'#title' => t('Taxonomy'),
'#maxlength' => 255,
'#description' => t('Can be either text or code. All values must be separated with a comma'),
'#default_value' => !empty($_REQUEST['form_taxonomy']) ? check_plain($_REQUEST['form_taxonomy']) :
check_plain($form_data->form_categories),
);
$form['first_part']['post_status'] = array(
'#type' => 'checkbox',
'#title' => t('Status'),
'#description' => t('Click to immediately publish the item. Otherwise, create item and manually switch to publish one at a time'),
'#default_value' => !empty($_REQUEST['post_status']) ? $_REQUEST['post_status'] : $form_data->
post_status,
);
$form['update'] = array(
'#type' => 'submit',
'#value' => 'Update and create',
'#submit' => array('affiliate_hoover_uniqueform_build_form_submit')
);
$form['submit'] = array(
'#type' => 'submit',
'#value' => 'Create only',
'#submit' => array('affiliate_hoover_uniqueform_build_form_two_submit'),
);
return $form;
Note the clear association between the form attributes and their values.
With the Wordpress Settings API this is largely absent and I found it unnecessarily confusing when I tried to push it beyond basic use.
In the end I created my own Wordpress form API which I documented in detail on Pro Blog Design.
Less code is needed for Drupal development
Writing modules for Drupal means writing less code.
As an example, when you uninstall a module on Drupal the database tables are automatically deleted, while with Wordpress you have to create a database call in the uninstall hook. It's touches like this that when all added together create a far smaller code base.
Image may be NSFW.
Clik here to view.
What warms me to Drupal is I feel that I am treading on the footsteps of previous work stretching back years. Drupal developers are particularly forward in adding inbuilt functions to deal with the many issues they have faced in the past. One negative aspect of this is that there are hundreds of functions in Drupal which, considering the already chaotic nature of the thousands of native PHP functions, means a lot more time is needed to fully learn the Drupal codex.
Performance
In my experience Drupal performance tops that of Wordpress. I created a module called Affiliate Hoover for both platforms. The module parses CSV data and creates individual posts from the content. As as test I parsed one file with 1153 content items, Drupal took 14 seconds while Wordpress took 37 seconds to create 1153 posts.
The variable isn't because of my code. The actual process of parsing the file into arrays / objects ready for database entry takes less than a second. The rest of that time is used by the respective platforms creating database entries for each item.
Even when flicking between the two platforms, admin Wordpress pages have a noticeable time lag before they fully load while Drupal renders admin pages instantly.
Hosting servers
Both Drupal and Wordpress need at the very least a VPS but most likely a dedicated server. A big performance issue for Wordpress is the widespread availability of badly-coded plugins. If you start using a dozen of these in your build then Wordpress really has trouble coping on a server without generous memory allowance.
Online documentation
On a plus side for both platforms there are a ton of online videos and tutorials to refer to, with a particular help being the stackoverflow sub forms for each software item. Both, to, have a number of high quality published guides which are available for purchase.
Easy of use for non-technical users
The big win for Wordpress is its excellent admin section. This, I feel, is the main reason so many web designers are happy to recommend it to clients. The thought of handing over a site built with Drupal 6 to a client and expecting them to master it is laughable. Thanks to Mark Boulton's web design company Drupal 7 made dramatic improvements to the admin UX but there is still some way to go which I hope will be fully realised in version 8.
Theming
The next big win for Wordpress is its theming. It's a real pleasure to work with. The Drupal Theme API is horrendous. What with all the processor and pre-processor hooks there is often several different solutions to one problem. Please, just one solution for one problem and no more. Thankfully, Drupalistas now recognise this and in version 8 it will be replaced by the Symfony template system, Twig. Once implemented this has the potential to dramatically increase the take up of Drupal by web design agencies who need a faster and less complicated way of creating Drupal themes (time is money).
Conclusion.
There is no Drupal vs Wordpress debate. It's simply the case that one may be more suitable for a particular project than the other. Any commercial company should potentially be prepared to use either.
As detailed above, both have many positive sides to their API approach and each have some negative parts. Neither is perfect, but they are mature platforms much in demand by clients. If you are a professional developer it makes sense to learn both platforms so as to increase your opportunities in finding work.
If you are unfamiliar with developing for either or both here are some books that I would recommend:
Pro Dupal 7 Development by Todd Tomlinson and John K. VanDyk (Apress, 2010)
Professional Wordpress Plugin Development by Brad Williams, Ozh Richard and Justin Tadlock (Wrox, 2011)
Drupal 7 Module Development by Matt Butcher, Matt Farina, Ken Rickard, Greg Dunlap, Larry Garfield and John Albin Wikins (Packt, 2010)