Following right on the heels of my weekend at DrupalCamp, I've stumbled across a few rather interesting blog posts on how Drupal is perceived in other parts of the PHP development community. Thought I'd post the links and make a few comments here, since the issues being discussed are pretty relevant to my day-to-day work as a web technology guy.

The problem with Drupal

Our first stop: a recent blog entry by Sean Coates, in which he discusses his messy breakup with Drupal. I have to admit…although I work with Drupal on a regular basis (and mostly enjoy it), some of his criticisms really hit home—not so much as far as upgrade paths are concerned*, but definitely in terms of the way the code base is set up.

I think we can all agree that Drupal is an extremely powerful, flexible content management system, and that its underlying extension API has all kinds of potential—just look at how many contributed modules it's inspired. However, if you've spent much time working with one of the newer breeds of PHP frameworks (no secret: my favorite is Zend's), building custom functionality for Drupal can feel, well, a bit less elegant. Don't get me wrong; I'm regularly awed at how well Drupal can procure many of the benefits of object oriented code in an almost entirely procedural paradigm*. However, the amount of time it takes to learn Drupal's sometimes non-standard approach to standard design patterns can be a bit frustrating—especially when you already know how to implement those patterns in object oriented code (see Larry Garfield's Objectifying Drupal from last year's DrupalCon for some interesting discussion on this topic).

Drupal and "other frameworks"

That leads me to the same questions raised in another blog post I ran across earlier this week: is Drupal's success hurting the growth of PHP frameworks? The author argues that it's especially a problem when Drupal is referred to as a "framework" and then compared with, say, Python's Django framework…the comparison isn't really reasonable given that Drupal and Django are two very, very different types of "frameworks," but it's a common comparison nonetheless—and because Drupal's coding paradigms aren't "keeping up" with the latest magic-bullet framework trends, the comparison can give the erroneous impression that PHP frameworks are way, way behind.

The author points out, however, that despite the apparent advantages of the current wave of developer-focused frameworks (Zend, Symfony, CakePHP, and the like), Drupal continues to dominate in search volume (admittedly a pretty arbitrary test of popularity), and powers some pretty big-deal sorts of websites. The reason should be obvious: Drupal is not, first and foremost, a developer-focused framework—that is to say, you'd never download it solely so you could program in it; it's an end-user-focused content management system, and it has an underlying developer API that functions as a framework when you need it for super-custom functionality. By and large, you're supposed to build Drupal sites without programming; that's the point.

In other words, Drupal is a danged good choice for site building (and even for some more complex applications)…that's why UNT recently chose it as our official campus-wide content management system. I might prefer Zend Framework as a developer, but our end users aren't all developers; mostly what they need is a polished, end-user site building product, and Drupal gives them that (along with a whole lot of flexibility for the folks who do want to get their hands dirty…provided you understand how it works, you can use Drupal for just about anything).

But in a perfect world?

On the other hand, if there were a good, solid, stable Zend Framework based content management system that had the community support and contributed module base of Drupal, I might not be as much of a Drupal advocate. That is to say, if I could give my end users a polished CMS product and still enjoy a fully unit tested, object-oriented backend, I'm not sure I could justifiably continue calling Drupal the best tool for the job. This attitude is reflected in ServerGrove's response to the above blog post; the author argues that, if PHP frameworks want to be better known and more widely used, then PHP framework developers need to publish interesting, powerful open source projects ready for end users, using their favorite frameworks as the base.

I think the author hit the nail on the head pretty well…for whatever reason, these frameworks seem to be most often used for proprietary, in-house sorts of projects; they may be very powerful projects built on elegant, modern framework code, but they're seldom published or re-used, and as a result they never gain the kind of community momentum that Drupal has. That momentum is critical to Drupal's success: it's not about using the latest and greatest development methodologies; it's about delivering a product that

  1. meets the needs of end users as well as programmers,
  2. gets the job done well, and
  3. inspires a passionate, vocal user base.

I got to see some of that passion this past weekend at DrupalCamp, and I was impressed. Drupal certainly inspires its users, and that's something I love to support.

I'm still using Zend Framework and Doctrine for my blog, though, because dang it, I just like them too much not to. :)


  • If you've got the time to learn the details, Drupal updates are actually pretty easy to manage…we've been doing it fairly seamlessly on 300+ Drupal sites at UNT for quite awhile now, with the help of the drush command-line tool and a variety of custom shell scripts.
  • For the record, as much as the object oriented approach may be my personal preference, I will never sit here and say that procedural code is all bad; bad code can be written any which way you like, and I've written more than my fair share of OO clunkers.