WordPress, Drupal, Django, and the ongoing search for the ultimate web development framework

As promised in my last post, I’d like to take some time today to rant about WordPress.  Actually, let’s not rant today. Rather, I will gently share some of my thoughts about the platform, and talk a bit about my experiences with other web development platforms as a backdrop, while musing upon the merits of each:

I’ve used WordPress plenty of times over the years for basic blog sites, like this one and this one, and I think it’s a great platform for simple blogs that work out of the box without having to learn much or write any code.  But I’d never considered it a full-fledged content management system, and wouldn’t think to use it for anything other than the most basic site with only a few static pages and a news or blog section.

Recently, I was hired to create a website for a company that was planning to sell a new line of jigsaw puzzles.  Initially, I planned to use Django, which has been my platform of choice for creating custom web applications that don’t conform to the generic blog model. I figured Django’s model-view-template approach would lend itself well to this project.  Just define the jigsaw puzzle model, hand-craft all my HTML with Django’s template system, and give the client a basic interface to add and edit puzzle products with Django’s built-in administration app.  But even with all the nice “batteries included” in Django’s stack, the framework doesn’t come close to eliminating all the tedious tasks involved in any web development project, and had my doubts about the amount of time it would really take to deliver a client-friendly site complete with all the bells and whistles if I insisted on hand-coding everything in Python.  Since I’d heard good things about Drupal and its support for custom content types, I decided to set aside my distaste for PHP, broaden my horizons, and see if it could help eliminate some of the grunt work.

I bought a book on Drupal, and as I noted in my subsequent review of said book, my first impression was that Drupal is “a bloated mess hacked together by a bunch of script kiddies with nobody in charge.”  I was half kidding, or in other words, half serious.  I mean, seven full versions into the life of this content management system, over a decade old, supported by more than half a million users and developers, and you’re telling me that Drupal’s most popular contact form module won’t allow me to display data from the user’s submission in the confirmation page?  As in “Thank you, Jimmy, for your valuable input”?  And you’re going to tell me with a straight face that Views, the module that lets you build custom queries to retrieve and display your content, used by nearly half a million websites, and possibly Drupal’s biggest selling point, isn’t officially documented?  Well that’s just great.  Let me go grab a tub of ice cream and watch some screencasts.  Maybe one of these nice Scandinavians will tell me how to use contextual filters.  No, not really?  Oh that’s okay.  I’m sure that feature wasn’t important, otherwise someone would have documented it.

And I’m sure Drupal’s new Render API is the crystallization of years of web development wisdom, but really, how many layers of abstraction, process, and preprocess functions do I need to filter my data through before I can render a single HTML tag to the browser?

But all said and done, having completed this website for the client, I can say without hesitation that I’m very happy I chose Drupal for the project, bloated mess and all.  Drupal has made it incredibly easy to make changes to the site without having to write a single line of code, which is a huge boon for indecisive clients.  With Django, I would have had to deal with South migrations every time the client requested a change to the data model — not a huge deal, but the ability to just add and delete fields to a content type with the click of a button in Drupal is really nice.  And Drupal has been great for providing a user-friendly interface and media handling features out of the box.  I had fiddled around with some image resizing and management apps for Django on a previous project, and I don’t think there’s anything that comes close to the functionality that Drupal gives you out of the box with its core ImageCache module.  This turned out to be a particular stroke of luck for this project, which required multiple images of varying dimensions we hadn’t settled on in the design phase.  You want those pictures bigger?  No problem.  You want WYSIWYG editor with unlimited media uploading per page?  No problem.  You want the “more” link in a View block to link to a full page based on the value of a contextual filter?  Fffffffffuuuuuuuuuu…….

This brings me to WordPress.  For this site, my portfolio site, I had originally made a blessedly simple slideshow with three static pages, all coded directly in static HTML.  Then I decided I wanted a blog.  Drupal seemed a bit overkill to just tack a blog onto three pages of static HTML, so I decided to return to my good old friend, WordPress.  But how should I integrate it?  Should I just install it next to my existing static pages, under a blog/ subdirectory?  Or should I move the whole site over to WordPress?

I revisited the WordPress documentation to see what it had to say for itself:

Anyone who says WordPress is a mere blogging platform is covering for the fact that they haven’t been following the CMS’s explosive growth over the past couple years. Saying WordPress is only a blogging platform is like saying BMW is only a propeller manufacturer. In fact, the majority of the time, WordPress isn’t even used as a blog. With built in support for custom post types and custom taxonomies, if you can dream it, WordPress can make it a reality.

Custom post types and taxonomies?  That sounds just as good as Drupal.  Okay, I thought, let’s see just how explosive this CMS’s growth has been.

As it turns out, there is no built-in user interface for managing custom post types or taxonomies.  You need to either install a plugin or write your own.  So I took a look through WordPress’s plugin directory, and found a popular plugin called Types.  Looks good.  I installed it, and created a new “Project” post type that I planned to use in my portfolio slideshow.  Now how do I display it?

What?  I need another plugin called Views?  “Just $49”?!?!?  You have got to be kidding me!  Drupal gives me this for free!

Alright, fortunately, I am a whiz guru developer, and even scary PHP does not faze me.  Now where do I write my PHP code to generate the view?  The answer, it seems, is in my WordPress theme template files.  That’s right, forget about separation of logic and presentation, because with WordPress we have template files which are not template files, but in fact just PHP.  And that, it seems, is the secret to WordPress, that you can extend it to do whatever your heart desires not because of anything inherent to WordPress, but because it lets you write your own PHP, and PHP is a programming language that lets you do whatever you want because that’s what programming languages are for.

But that’s not my real gripe with WordPress.  Probably I just haven’t managed to unravel its documentation sufficiently to figure out how I’m actually supposed organize my code so that the theme layer is concerned only with presentation.  The real issue is that the plugin directory and surrounding community seems to be a zoo.  All of WordPress’s community developers seem to be competing to produce their own version of the same plugins, complete with both free “lite” and paid “pro” versions.

This is where I think Drupal really deserves to be applauded.  Drupal’s contributed module directory seems to be growing smaller with each core version release, as module developers are teaming up or actively stepping aside in support of more popular modules with the same or similar functionality.  All of Drupal’s modules are free and fully functional, with no crippleware to be found.  (Well, maybe not fully functional, but at least the developers don’t seem to be intentionally withholding or charging for extra functionality.)  I hadn’t fully appreciated this while working on my Drupal project, but after getting a taste of what the WordPress community has to offer, I feel almost converted.  If only it was written in something prettier, like Python…

One thought on “WordPress, Drupal, Django, and the ongoing search for the ultimate web development framework

  1. Great comparison write-up. I started building complex sites with WordPress, only to be forced to write a lot of my own php functions, which didn’t feel sustainable nor secure. I quickly moved to Drupal, where I rarely need to write custom functions. I’ve been using Drupal for years and love the platform. WordPress just doesn’t hold up when you want more than a blog and a few pages. Not to mention the theming community of WordPress is a tangled mess that’s not well vetted in my opinion.

    I ran across your post researching django, and plan to spend some time with python next. Even though I actually like PHP, django/python likely has more power than what I’m used to, and thus sounds fun and exciting.

Leave a Reply

Your email address will not be published. Required fields are marked *