Wherein We Muse Over a Case Study of a One Day Wordpress-to-Drupal Conversion

Joeri Poesen //

A sad tale of neglect

We’ve been running a small educational non-profit – Edulogos – for over three years now. Until recently edulogos.org has been little more than a Wordpress blog with a few extra pages and an off the shelf theme. It was one of the first sites we installed on our then brand spanking new Dreamhost account and we were happy with the results.

Over time however, teaching and project work got in the way of publishing much content. Maintenance was neglected and the limits and drawbacks of Dreamhost became a detractor for giving the site the love it deserved.

We decided it was high time to redesign the site and move it over to Drupal to give it room to grow. Like repotting a plant. “Liefde en substral”, as they used to say in our home country.

The road to Drupal

Knowing how data migrations are seldom without incident, we prepared for the worst. Surprisingly the migration was over before we got to our second cup of coffee that morning. The rest of the day was spent selecting and tweaking a theme and setting up some notification functionality.

We kept the new theme and functionality as simple as possible and used only a small number of tools and contributed modules:

Tools used:

Contributed Drupal modules:

Theme:

Module download and installation

Using Drush is not required, strictly speaking, but do yourself a favor and get to know it. Drush is a command line tool that lets you do a variety of very interesting things much faster than doing them click by click through your file manager and Drupal administration interface.

In this case, we used Drush to download and install Drupal 6.15 and the modules and theme listed above:

cd /var/www
mkdir edu
cd edu
drush dl drupal 
cd drupal-6.15
drush dl trackback pathauto rules mollom twitter views admin_menu wordpress_import summertime
drush enable trackback pathauto rules mollom twitter views admin_menu wordpress_import

Again there’s nothing stopping you from downloading individual .tar.gz files, unpacking them, moving them to sites/all/modules and cleaning up the archive files. You’ve got to admit though, that drush dl and drush enable are a pretty sweet deal.

Migration and site construction, step by step

1. Export from Wordpress
As per the wordpress_import instructions, we went into our Wordpress admin interface, exported our content into an xml-file and saved it locally.

2 Import into Drupal
We made sure Wordpress_import and its dependency Trackback were enabled and made our life a little easier by installing Admin_menu – we’re suckers for dropdown menus.

Wordpress_import takes a previously generated Wordpress export file and imports content into nodes, comments into, well, comments and categories into taxonomy terms. Users are created on the fly too, if they don’t already exist.

Knowing how tricky data migrations can be, we were pleased the data import went flawlessly. Granted, the old Edulogos site only contained a good hundred content items, one user and maybe a dozen categories, but still. Kudos to Yann Rocq for a tool that works as advertised.

3. User friendly and search engine friendly URLs
We enabled Pathauto so our blog posts and other content items get nice and tidy urls like /blog/monday-pancake-day instead of /node/42.

4. Avoiding comment spam
Though captchas are an ok solution, we really like the way Mollom attacks the problem. Mollom is a free anti-spam service that will analyze the contents of comments and present the user with a captcha if and when it thinks a message might be spam.

The only thing we needed to do here is create an account at http://mollom.com, generate a set of API keys, enable the mollom module in our Edulogos site, enter the keys and select which forms we want Mollom to protect. In our case it made sense to let Mollom protect the comment and contact forms.

5. Automatic comment notifications
Wouldn’t it be nice if content authors would be notified of new comments? We thought so too. Enter Rules, a marvelous module that allows you to set up specific actions that need to be performed automatically under certain conditions when certain events (triggers) occur.

We set our notification rule up like this:

  • trigger: after publishing a comment

  • condition: no specific condition

  • action: send mail to author of content that received the comment

Action configuration screenshots:


6. Twitter integration
We wanted to promote our twitter account (twitter.com/edulogos_vzw) and show our latest tweets in the sidebar. Walkah’s Twitter module does exactly that. Actually it does much more than we need, so we know there’s some nice functionality waiting for us when we’re ready.

We just wanted to display the tweets of one single twitter account in the sidebar. We entered our twitter credentials and then went to the block administration screen, only to find no twitter related blocks for us to use. After a couple rounds of clearing the cache, running cron and refilling our coffee mugs, inspiration hit us and we turned on the Views module.

Lo and behold, a ‘user tweets’ and ‘all tweets’ block magically appeared. We put the ‘all tweets’ block in the right sidebar, and Bob’s your uncle.

Making her look all nice and purdy

In terms of visual appearance we weren’t going for high originality. We just wanted a nice and clean, professional yet simple design. The Summertime theme fit our needs nicely and we spent the rest of the afternoon tweaking the css, playing around with font sizes and making the Twitter block look nice.

Taking her out and showing her to the world

Everyone has their own way of deploying a site, whether it’s through FTP, SSH, a version control mechanism or a homegrown script. We used git, a distributed version control mechanism, together with Github, a git repository hosting service. How we fit git and Github into our workflow is a story for another day.

A cap, a cap, our kingdom for a recap

We’re very pleased with how we migrated our old Wordpress site to Drupal, picked and customized a new design and added new functionality – all within a single day and 8 to 10 coffees.

We were able to keep the number of contributed modules to a minimum and didn’t even make a view for the front page: since we had only one content type, we just use the default front page (http://example.com/node). We’ll have a lot less spam comments by using Mollom and we’ll be quicker to respond to comments now we have automatic notifications in place.

Finally, the code is now under source control and we have a script in place to deploy from Github and restore an hour-old database backup whenever we want, but more on that later.

If you’ve got any short-but-sweet redesign/redeployment stories to share, leave a comment!