NOTE: This is likely to a multi-part series on the migration of dooce.com 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 dooce.com, 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 dooce.com 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
- 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 dooce.com. 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. Drupal.org 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.