A little while back, I read Dougal Campbell’s article, WordPress and Drupal: Convergence?. It certainly seems that two of the most widely-used website publishing systems are learning a lot from each other, to their mutual benefit.
My background is in Drupal development, but I’ve recently been putting some effort into learning WordPress too. I fairly close to launching this blog with my own WordPress installation, and although I decided not to for a number of reasons, it’s helped me get some good insight into the things WordPress is good at, and the kinds of projects where it may be a better fit than Drupal. I found the biggest problem was that I’ve developed most of my approaches to website building “the Drupal way”, and so I hope this article will offer a bit of a leg up for others coming at WordPress from a Drupal perspective.
CCK → Custom Post Types UI
Most Drupal websites use the Content Creation Kit (CCK) module, which allows us to build a wide range of content types (pages, blog entries, events, products, links, e-cards, etc.). In fact, the CCK approach has become so fundamental, it has been incorporated into Drupal 7 core.
The WordPress equivalent is the Custom Post Type, for which there is the Custom Post Types UI plugin (with an excellent tutorial video there).
The Custom Post Types UI can’t get you anywhere near as far as the CCK UI in Drupal – particularly as CCK and other modules support a huge range of field types for handling dates, media, content relationships and so on. However, the core Custom Post Types API in WordPress is much more powerful than the UI plugin, and this power can be accessed through custom theme or plugin development. Alan Levine has a good quick-start article here.
Other useful plugins here include More Fields and More Types — which, combined, would provide a reasonable replacement for the simplerCCK text-based fields. You may well have to live without fields for file uploads and content relationships, unless you’re prepared to write your own plugins.
Views → custom themes
Once some content types have been added to a new Drupal website, most people use the Views module to create displays of their content—a blog list, a product catalogue or a playlist.
So far, I haven’t found a direct replacement for this. Instead, you’re going to need to get your hands dirty coding a custom theme. Luckily, WordPress has a themeing/templating system that is arguably simpler than Drupal’s. Of course, as a Drupal-fan, I’d be inclined to say less powerful too, but if I allow myself too many quips like that, we’ll never get anywhere
Both Drupal and WordPress have theme inheritance — one theme can inherit all the properties and functionality of another, and then override or extend it. This is a solid approach to development on either platform, although I think I would depend upon it more with WordPress. If custom content types and views are hard-coded into themes, I can easily imagine wanting to build a portable theme that supports, say, calendar events, and using this as a parent theme on any site that needs a calendar.
For many purposes, WordPress’s media management is perfect, straight out of the box. It’s really tightly integrated into the post editor in a way that Drupal developers must all secretly envy. So many may find this aspect of WordPress a definite “pull-factor” away from Drupal.
On the other hand, I’ve built up an approach to media management with Drupal that is increasingly common, and unfortunately quite hard to implement with WordPress.
I often implement a solution using a combination of the Image Field and Image Cache modules. Here is an example in action on the City of Sanctuary website where I’m using this approach:
This image upload field was created for news content types. For displaying these images, I can set Image Cache to show them as a small thumbnail in teaser lists and a larger picture when viewing the full news article. Each image size is generated by a preset determined with Image Cache, the original image file is kept safe, and Image Cache allows you regenerate all the images for a given preset if your site layout needs to change, or if your client tells you that they’d like differently sized images.
Achieving this kind of thing with WordPress is not quite as straightforward, but it is partially doable. WordPress now has a “Featured Image” option in its media gallery. Not all themes will display your Featured Image, but it’s fairly easy to build it into your own theme or add it to an existing one. Featured Images can be regenerated globabally if you decide you want to change the sizes that are displayed, and you can have your theme display differently sized images in different locations. The drawbacks are twofold: (1) the user interface for a Drupal Image Field is a bit easier to work with than WordPress’s media system, and (2) the Featured Image system doesn’t give you the “power tools” which Image Cache does — i.e. cropping, rotating, watermarking, etc.
However, perhaps the Image Cache / Image Field approach is fairly specialised, and many Drupal developers will get along quite happily with WordPress’s tools here.
Many of us Drupalistas have grown to love the Drupal UI model, a key part of which is that there is no seperate admin interface. Unless you’re tinkering “under the hood” of your site, most of your interaction with it (writing posts, managing comments) is done on the front-end, and even the admin pages are presented in the same templates as your public-facing site.
WordPress does have a very beautiful and highly customisable admin area, so it’s not too bad a place to find yourself stuck. On the other hand, if you really miss being able to work on the front end, there are some handy plugins available.
The Front End Editor is a good one, going even a step further than Drupal and allowing you to edit literally anything in place on the front-end – even site settings and category names.
The WordPress Admin Bar is also really super, as it includes a link for writing new posts from the front-end. Admittedly the Admin Bar links all take you to the back-end admin area, but, like I said, it’s beautiful, configurable, and… ah, you’ll get used to it
“Input formats” are an important aspect of Drupal, allowing you to control how HTML or any special syntax in your posts is interpreted and displayed on your site. This is an aspect where familiarity with The Drupal Waytm has left me feeling short-changed by WordPress.
In Drupal we install extra input formats (such as Textile, or the GeSHi syntax highligher) as modules. Once installed, we can configure most of them and change the order in which they run. This allows us to fine tune which formatting makes it through to be displayed, and which is cleaned out; and helps us to resolve any conflicts between filters.
In WordPress, there are plenty of plugins which can deploy different input syntaxes, and some themes (and WordPress core) do some text processing as well. But, perhaps because this system isn’t so open and configurable in WordPress, it can get tricky. As I was building this blog with WordPress, I picked The Erudite theme, and installed the GeSHi filter plugin. Unfortunately, typographical processing done by either the theme or WordPress core replaced the straight quotes in my code with “smart quotes” or “sixes and nines”. Any visitors copying this code would find it to be broken, unless they first replaced all the quotes. Now this wouldn’t be an intractable problem. I could have hacked or removed the typography stuff in The Erudite theme, or I could have picked a different theme or written my own. But it’s definitely something to be aware of.
Website management — no drush
Depending on how you like to manage your website, there may or may not be issues here.
Drupal comes with built-in update notifications, although (prior to Drupal 7) you have to manually upload the updates to your server withFTP, log in as “user 1” (akin to the root user on Linux, with global privileges) and run an update script—all a bit of a pain. Until you discoverdrush. No, it’s not an STD. It’s a phenomenally powerful command line interface for Drupal. As long as you have SSH access to your server, you can upgrade your site, install extra modules and tons more with a simple drush command.
Not to be outdone, WordPress can update and extend itself from your admin area, without you needing to use anything so primitive as a command line. However, I remain sceptical about how secure this is. For WordPress’s update systems to work, it needs write-access on the entire installation—something I’m inclined to view as a security risk. My workaround was to write a shell-script which changes the file permissions to allow WordPress to update itself, and then another script to lock the permissions down again afterwards. Problem solved, for me — easy, secure updating and about as easy as drush, once it’s set up.
Likewise, another feature of drush I use a lot is the built in command for creating a MySQL database dump—also pretty easy to duplicate with a shell-script, and no root-access required.
Cron and scheduled operations
A key part of setting up a new Drupal installation is to set up the scheduling of automated tasks with cron. From what I’ve seen so far, it seems that WordPress triggers these scheduled tasks internally, when pages are viewed – similar to the poormanscron module for Drupal.
I would prefer to handle this scheduling externally, so that some page views don’t result in lengthy waits while scheduled tasks are being performed, but I’m not yet sure what the options are with WordPress. This year old forum post might offer a starting point, and there is also the Cron Functions reference in the WordPress Codex.
Moving the site across domains
This is one aspect of WordPress that’s plain ugly. When WordPress installs, it adds two or three references to your base URL to its database. So if you move your installation from one location to another, and the base URL of the site changes, your site will break and you won’t be able to log in and fix it. With Drupal, I’m used to being simply able to move or copy the installation between locations for testing, development or demonstration purposes, and because Drupal figures out its base URL dynamically this is never a problem. To play these kinds of games with WordPress, we’ll need to get used to changing the base URL values in the database every time we move or copy our site.
The URL values that need to be changed on any site move are in the
wp_postmeta tables. I’m sure a shell script could be written to make this less of a chore each time, and I hope that in the future WordPress either puts the base URL in a config file, or susses it out dynamically.
So that’s the story of my WordPress experimentation. I’m sorry that I wasn’t confident enough with WordPress by the end of it to adopt it on my blog. But I hope this article has practically demonstrated the kind of Drupal/Wordpress convergence that Dougal Campbell mentions. I also hope I’ve shown that there is a lot of value in trying out an alternative website platform now and again. Even if you decide to stick with your existing system, you’ll pick up lots of ideas for improving it further.
As a Drupal specialist, I find WordPress to be an inspiring project. I look forward to helping Drupal incorporate some of WordPress’s strengths, and I shall be actively looking for an opportunity to build a website with WordPress and explore its possibilities in greater depth.