Drupal to WordPress Migration: Prologue

NOTE: This is likely to a multi-part series on the migration of from Drupal to WordPress. There’s more than one reason I don’t list developer on my résumé… So if you have tips, pointers, observations, excellent code resources, leave a comment or drop me a line.

I don’t hate Drupal. Drupal does not suck. Drupal is a solid platform to use as a content management system. Solid. Any complaints I might have: too many module dependencies where a critical module relies on a critical module or two from somebody else, not many features built-in for a modern CMS, e.g., many modules should be integrated into the core and upgrading needs to be less terrifying and costly. These issues are really the same for any publishing system. How bad are the modules/plugins in terms of being kept updated and how often do they break when the core gets updated? One of the considerations was indeed trying to answer the question: How difficult will it be to stay up to date?

Since our migration to Drupal, many install packages have been created with recommended modules and theme frameworks. While that takes one farther down the road, there is still a heavy development cost to maintain a Drupal site. Before those of you who are amazing Drupal developers tell me I’m clueless, I should caveat this whole thing with: every system has at its heart the ideas that the original developer(s) created. Those ideas either resonate with you or they don’t. As a business, you have a choice: you either learn that system or you pay someone to get you where you want to be. We chose the latter.

Drupal has a complex theming system; it’s more difficult to get where you want without understanding several layers of abstraction. Drupal can be expensive to maintain if you aren’t living in Drupal every day, all day. Finally, a paralysis set in. If you have a feature or a module needs upgrading, you might find yourself quickly painted into a code corner where one module upgrade hoses another vital module or you have to update the core, but the core only works at version X.X with another vital module. While this isn’t always the case with every framework, for our business, the fear of having a site outage kept me from experimenting, even on my local sandbox machine. I think this speaks to those original development ideas that birthed Drupal and the philosophies that have steered its growth. These are not inherently good or bad. Just something to weight when considering a publishing platform/framework.

To be fair, any platform that has modules, plugins, extensions or relies on third parties to add or build features has similar drawbacks. Drupal has served Blurbodoocery very well, serving up a quarter of a billion pageviews since switching from the venerable (and also not hated) Movable Type in November of 2007[1. Pageviews according to Google Analytics]. So why switch? Why fix something that isn’t broken?

Two words: Mobile devices. Two more words: development cost. I bring up mobile not just because more and more people are reading the web using mobile devices. It’s that the mobile device is becoming a primary computing platform. In short, being able to quickly shoot, edit and post photos from a phone is becoming more and more important. It was one of the things Heather asked for when we first did the spec for this redesign. Being able to manage a site from a mobile device is something that has been a holy grail since the first smartphone was powered up by a blogger. While Drupal can be managed from a phone or tablet, it’s not something I’d recommend without major theming work on the admin screens and requires a bunch of modules. Drupal on a mobile device requires some hoop jumping. WordPress has an actively developed app that can notify you of new comments, let you share a photo quickly and make edits on posts in a lightweight interface. So being able to post and manage a site by mobile device: highly desired. WordPress has the advantage.

WordPress isn’t the only game in town, but for now, if you run a business where you want to control your site and not be beholden to a third party, WordPress is one of the better options, if not the best for managing content. All of the issues that kept us from using WordPress in 2007 have long been alleviated. There are still some issues at the core of WordPress that I’d love to see ironed out: Tag and category management (more built-in controls to merge, switch one to another, etc. without needing a plugin), more media/image handling, better control over different image size crops and a simpler interface for posting. Or at least a simpler choice for editing. The visual text editor is problematic as well. Nice idea, but I’ve seen many posts mangled by the visual text editor. Fortunately, that can be turned off.

Still, for, WordPress is the ideal choice. Ironically, since the upper 2.x versions, WordPress has moved closer to Drupal in terms of more extensible theming, template management and template hierarchies. Some of the theme frameworks available are their own complex system within WordPress. Themes are no longer a list of PHP files, a stylesheet or two and an images folder. This has been true for quite awhile, but the level of some of the themes available is mind-boggling. One of the bigger draws to Drupal was it’s excellent built-in caching (made better by modules). WordPress plugins have matured and handle caching[2. W3 Total Cache. Fantastic and highly recommended.] in a more efficient way, which for means memcached & APC.

So while WordPress isn’t perfect, it fit the criteria as follows:

  • Mobile app, not just for posting, but admin features/managing and new comment activity as well
  • Ability to scale on heavy traffic days
  • Active development community; easy to find solutions and tips for adding non-core features
  • Future proof
  • Maintainability/upgradability
  • Cost (development, hosting/server hardware, speed of pageloads)

Initially, the mobile app was down the list, but when Heather asked how hard it would be to post a photo from her phone fairly early on in the process, I knew that WordPress would be the way to go. I’m certain there are ways to do it in Drupal. However, WordPress has some nice features when it comes to images. You can determine the various sizes of images you want across your site, add a few lines of code to the functions.php file and when you upload a large master image, WordPress will build all of those images for you. Posting a photo from a phone has a bunch of automated things that happen to keep the content from breaking and makes the process fluid and low-friction.

Scale. There have been numerous very heavy days of traffic on The ability to handle those traffic spikes is key. Yes, a good homepage/landing page design can ease the server burden, but the framework/system itself should be able to handle a spike in traffic. Yes, most site failures are likely hardware related, but we’ve developed contingencies and redundancies to handle the hardware. The software shouldn’t be a barrier to pages being served. The aforementioned cache plugin is a huge help on heavy traffic days.

Development/developer community. WordPress has a much larger community of developers. Searching for solutions to code issues or feature requests yields more in terms of search results—and more usable—results. Drupal has fantastic developers. This isn’t meant to say that Drupal doesn’t have this. is a great resource for development. But there are exponentially more WordPress development resources available.

Future proof. No system is future proof. This is a pipe dream that one must chase, if only to come up short. One post-launch issue is fixing unforeseen redirects from surprisingly still active URLs including those from over 10 years ago. Drupal has pathauto that handles a lot of rewrites, but that also hid some of the issues. There have been some complimentary modules to unhide those issues, but we’d still be faced with handling redirects. I’m also currently auditing the content for a canonical URL. I’m also having an internal debate about having anything after the base URL other than the title of a post. That debate will continue as I write and rules and schema conditions. That will cause a ton of issues regarding social network links, likes. I’m looking for a way to maintain existing canonical URLs with Facebook and still have URL flexibility going forward.

Maintainability/Upgadability. WordPress has some nice automated features for upgrades. This is key for sites where you want to build it and do minimal maintenance. Drupal has some upgrade features, but I’ve had to roll back to a more stable set of modules more than I’d like to count due to use of the upgrade feature. This plays back into the module dependencies. Plugins for WordPress use a separate from core upgrade process (you can upgrade plugins individually or alongside other plugins. The only downside is that, as with Drupal, if a plugin isn’t actively maintained, any changes to the core can wreak havoc. A sandbox environment for testing is critical. But even then, you just don’t know how some features will react until you get them going on an actual site with real traffic.

Cost. Drupal is more expensive, without a doubt. That is not a complaint. I knew that going in 5 years ago and it’s still true. Custom features have a premium. Paying a developer will save massive amounts of time, but you are paying a developer. In this way, Drupal is like an exotic car that requires a team of specialists to tweak. Once it’s firing perfectly, it can stay that way for a long time. But those tweak costs will be high. Again, not a complaint. Just an observation.

Finally, researching the move away from Drupal involved a lot of searching. Most migrations involving Drupal are away from WordPress to Drupal. What information is available is scarce and the motivation for me writing this whole thing up.

Next up in the series: Act I: The process of redesigning and development.

  • Jessica Dennis

    I set up a teeny tiny site on Drupal that needed very little advanced functionality, as it was mostly static pages, and it was *still* a total nightmare and pain to maintain. Alongside that I was running several sites on WP, and, well, one-click updates to core and plugins? Count me in. Plus all the stuff you mention about the WP community, and the WP codex is also (in my opinion) much friendlier than the Drupal docs.

  • Sara Halliday

    I’ve noticed the last few weeks that loading the site freezes my work computer (running Chrome) until the page loads. Not sure if you’ve experienced that but I thought I would note it in case it’s something to do with the migration.

    Doesn’t discourage me visiting, obviously, but I do have to make sure it’s not a time when I’m technically supposed to be working.

    • Sara Halliday

      It seems to be only posts with photos, by the way. I’m also clicking over from Google Reader if that would ever make a difference.

    • Sara Halliday

      Of course I can’t replicate it now that I’m trying. Perhaps ignore me altogether.

    • blurb

      Have you done a shift-refresh? We’ve made some code changes and your browser might have older code. Might.

      • Sara Halliday

        It must have been before you migrated. I haven’t had an issue since. :)

  • Greg Fox

    I need to do the same with a few of my Drupal sites. I originally set them up for blogging, but they are more of a liability than anything else. My wife and I just need a simple platform for writing our posts. WP handles this much better than Drupal.

    Much like yourself I’ve found many posts about going from WP to Drupal, but only a few going the other way. My sites are small in comparison to your undertaking, but I’m hoping that your posts contain enough info that I can replicate your process.

    Are you going to be preserving users, comments, posts, and permalinkes?

    • blurb

      We are still cleaning up the comments for Disqus. The XML is pretty jacked. The users are stored in the community database. I’ll discuss the permalink situation in a later post.

      • Gordon Agress

        What are you using for handling the XML? xmlstarlet is useful commandline tool for XML stuff, you can run XSLT transforms and XPath queries through it. And Python has some good XML handling libraries.

        • blurb

          xmllint. Kludgy. I’m going to look into BBEdit as well; the files are pretty big for text files. Not insane big, just pretty big.

  • Tiffany

    Just an FYI, the site won’t load properly on my iphone or ipad. The posts are all stretched out vertically. Pictures are not visible, text not readable.

    • blurb

      Which iPhone and iPad are you using to access the site? I’m guessing older versions… I thought I had nuked all the bugs for older iOS devices. I’ll take another look at the CSS.

      FYI, this is a known rendering bug with a certain version of Safari on iOS. Which makes it relatively easy to fix.

      • ska1ser

        On my 3G iphone the images are crazy stretched out.. it’s horrible to try to read on the Iphone.. my Ipad2 works and my 5 year old Mac laptop is fine in Firefox… but it’s like Tiffany (above) was saying… pictures are load up for a second and then are stretched like gum and you have to scroll for a millenia til you get to the words… So usually I’ll just wait til I can get to my Ipad or computer… 1st world problem. :)

      • SaveKitty

        My droid has problems with the images as well. Looks like the scaling on the fly is off. All the aspect ratios are off on my phone.

        • blurb

          Thanks for sharing this. I’ve been hoping somebody on Android would jump in and mention if they had issues or not.

          Which version of Android are you running? I think it’s a CSS issue, but I need to verify the version of Android and/or your browser.

          • SaveKitty

            I’m on 4.0.4 (ice cream sandwich). I can check my droid tablet too. I’m a web designer so I have access to um.. lots of devices. lol

    • Tami Kay

      I have the same problem.

    • blurb

      How about now? I just made some tweaks to the CSS. You might need to refresh the page a few times for it to work.

  • Kristan

    Looking forward to reading more about this behind-the-scenes process!

    Btw, it’s no biggie, but I’m on a 13″ Macbook with 1280×800 screen resolution, and doesn’t fit in my Chrome window. It cuts off about halfway through the right sidebar. It bothered me at first — really only because the right edge of the header gets slightly cut off too — but I got used to it after a day or two, hehe. Just wanted to let y’all know, in case you cared.

    • blurb

      Can you do me a favor and hold down the command key and while keeping it held down, hit the “0” (zero) key? Then tell me what happens?

      If that’s not the issue, is your browser stretched as wide as your screen? The site should easily fit in a 1280 width.

  • blurb

    Thanks for the screenshot. That is what it’s supposed to look like at 1280. So maybe I need to do another breakpoint. I’m not upset, just want to know use cases. How wide do you normally keep your browser?

  • blurb

    What happens if you drop it down to 1024 wide? I may have to put in a breakpoint for anything under 1280, but I figured that the 1024px wide breakpoint would cover most people.

    This is an interesting edge case. From our analytics, we know that most people hit the site on desktop machines. Of those desktop machines, ~97% are at a minimum 1280 wide. The smaller windows are clearly phones or tablets and I’ve built breakpoints with their own CSS for those devices.

    Let me know what happens after you do a shift refresh and then size your browser to 1024 or under. You lose some of the site chrome, but everything should be there.

    • Kristan

      Hm, j/k, can’t email you the screenshots, b/c I don’t have your email. So, uh, here they are, ghetto-ly stitched together. 😛

      • Kristan

        Hm, maybe that file was too big for Disqus. Attempt #2.

        • blurb

          According to my measurements, the images show your browser to be at 893 pixels wide, minus the scrollbar means 878 is the size of your viewport.

          I wonder if it’s safe to say that most people have their browser window full screen on a laptop? Or maybe your case isn’t an edge case?

          Either way, thanks for sending the screenshots.

          • Kristan

            I would imagine that users on a PC laptop would be most likely to full-size their windows. (I know I did when I had a PC.) With Macs, the green “zoom” button doesn’t usually maximize width (as you know) so users may be more likely to set their windows at a “comfortable” size for their screen. And everyone’s definition of “comfortable” will differ. I like to be able to access files on my desktop, so I set it around 1000-1100px wide normally, giving me that visibility of icons around the edges. Not sure what other people do.

            But yeah, I hope I didn’t come off as complaining, because I only meant to offer information about the new design. :)

            • blurb

              Didn’t feel like you were complaining at all. Thanks for taking all this time to share how you read websites. I need to do some more CSS work…

  • blurb

    Are you running iOS 6? If you are still on 5.x, Safari is buggy. If it is still happening after iOS 6 upgrade, that is odd, as I have an iPad 2 on iOS 6 and the site loads fine.