Migrating from Drupal to WordPress

On my personal blog, I just posted a series of Mysql database scripts that will help you migrate from Drupal to WordPress (Drupal 6.22 to WordPress 3.4.2 specifically).  I was very surprised to find so little out there on the subject.

You can read my full post on the script at Allthingscahill.com – but I thought I’d put a few observations here.

  • Drupal content in the 6.22 version at least contains tons of inlines styles.  This will make it hard for you if you’re doing a major theme shift.  On the other hand, your content block will most likely maintain its formatting if you’re not making a big change.
  • The db to db script I worked with does not move the images into the media library. If I had more time and if this site was staying in WP, I’d definitely go a different route and use the db scripts to create a WXR file for import so my content is properly moved.
  • Drupal categories apparently aren’t completely unique.  It was a problem for my move, as Snark appears to be the same category slug as snark to WordPress.  It took a little data massaging to get it right.

Well, give the post a read if you’re looking for more info on how to migrate Drupal to WordPress.  If I do another move, especially from Drupal 7, I will most likely create a WXR and perhaps I’ll release the script for reuse or hand it off to my friends at Automatic (the folks who make WordPress).

WordPress Plugins – The Good, The Bad and the Ugly

<Cue Ennio Morricone’s theme from The Good, the Bad and the Ugly>

For most of the problems I see in WordPress, we’ve got no one to blame but ourselves.  I get a lot of emails, calls, etc. and they generally come down to one thing: plugins that are improperly configured or are causing conflicts with other plugins.

I typically run my WordPress installations with around 5-6 plugins, all installed to provide very specific functionality and all of which I have closely reviewed to make sure they’re going to do what I want them to do, and not bring “other functionality” to the party that I don’t want.

Before we start, I should probably offer a definition of what wordpress plugins are:

 A Plugin is a group of php functions that can extend the functionality present in a standard WordPress weblog. These functions may all be defined in one php file, or maybe spread among more than one file. Usually, a plugin is a php file that can be uploaded to the “wp-content/plugins” directory on your webserver, where you have installed WordPress. Once you have uploaded the plugin file, you should be able to “turn it on” or Enable it from the “Plugins” page in the administration interface of your weblog. The WordPress source code contains hooks that can be used by plugins. <from the WordPress Codex Glossary http://codex.wordpress.org/Glossary>

Fairly benign, eh?  Well we should remember these, along with, to a lesser degree, theme files, the main way in which we extend the functionality of the WordPress system. Anything from adding a Facebook “Like” button to adding on a full user management system.

My argument against using too many WordPress plugins isn’t the one you’d expect.  I don’t worry about plugins slowing websites down.  Look at WordPress.com – they use 200 plugins per page load (*I should note this is second hand info from Wordcamp SF this year).  If plugins are slowing page load, then it’s due to your use of poorly coded plugins.

My argument against excessive plugin use comes down to this:

  • Plugin Conflicts – the more you’ve got, the more likely your’re going to have something go horribly wrong.
  • Debug Nightmares – There’s a showstopper bug and the site is running 30 plugins. Have fun, Mr. Developer…
  • User Experience – the more you modify the system, the more you’re going to have trouble training new users.  I should also point out that training is generally an ongoing issue for companies.
  • The Bad Apple Affect – even with a modicum of due diligence on your part, it’s possible your going to let a bad plugin slip through the vetting process.
  • Most Plugins Aren’t Essential – and a very high percentage are never, ever used by the customer.  So why are they there?

So what makes a good wordpress plugin? My general list:

  • Simplicity – something that provides the fuctionality I need and not much more.
  • Popular Acceptance – if the rest of the community is using the thing, then we can reasonably expect the developer will continue support.  Even if the developer doesn’t, there’s a good chance someone else will, if the need arises, as notably happened when the original develop of All in One SEO gave it up, and the development responsibilities were picked up by hallsofmontezuma.  Just because lots of people use a plugin doesn’t mean it’s good, but it does increase the likelihood.
  • Code Accessibility – (for major functionality) it has become a practice for some commercially developed plugins to user obfuscated (encrypted) code to protect their intellectual assets.  I support their right to do that, but I will do everything in my power not to use plugin that doesn’t allow me code level access.  Just last week I was debugging an issue for a customer, and found the bug was in code that had been obfuscated.  We’d already found we had trouble getting support from the plugin supplier, so we were essentially at a road block.  I was able to provide a work around, but there was no reason we should have had to do that.
  • General Manners – if the plugin inserts links into my site to itself without providing a way to turn them off easily, or if it adds a feed from the developers site into my admin console without providing a way to turn it off, I won’t use it.

My general rule when it comes to plugins is this: Know what functionality you need, why you need it, and how the plugin provides it.