Apr
2
The Drupal use case
I have written before that drupal is the worst possible content management system, apart from all the others, and a recent comment by webchick has only cemented this opinion, at least with regards to medium-scale web development projects.
In my youth I was responsible for several content management systems. This was back in the day when there were at least as many web application frameworks as there were web application developers; halcyon days when a man or woman could enter their office in the morning, boot up a less than perfect IDE (probably HomeSite or BBEdit) and emerge at dinner time with a homegrown CMS.
The truth of the matter was that content management systems were simple: little more than (notoriously poor) wysiwyg editors slapped in front of databases with some kind of taxonomical structure to organize them and a template to wrap around the contents. Even an Economics major, such as yours truly, could put one together. And lo, that’s what I did, and to my surprise some of them are still ticking along quite happily to this day, fit for purpose in their own limited domains.
I expect drupal version 1.0 was much the same, and that dear old Dries had just as much fun writing it. Even if he wasn’t getting paid and I was.
Regrettably, on the level of individual job satisfaction, we shall not see those days again. Once a solitary exercise, CMS development today – as Hilary Clinton might say – takes a village. Of course, like most villages, you wouldn’t want to live there. But it does give me the excuse to tortuously extend a metaphor.
Developers are a maverick bunch, and by virtue of being the most developer-centric of the leading open source CMS systems, Drupal has long been a frontier town, a dweeby Dodge City for code cowboys who emerge from their mother’s basements only to trip noobs on their way through the double doors at the Mountain Dew Tavern. Nevertheless, some astute moves on the community development front have created a loose semblance of order: lawmen to enforce the two space pseudo tab indent in all contrib modules, and to round up a posse to tackle any OOP-related sedition, etc.
From a management perspective, the reason to adopt drupal is neither the elegance of its code nor the “humility, encouragement, mentorship, collaboration [and] empowerment” supposedly espoused by its community. Primarily because I am skeptical as to the existence of either. No, the reason to adopt drupal is that, both beyond and below a certain scale or particularity, it is rapidly becoming the only game in town, aside from enterprise level systems which you cannot afford in the short term and a grow-your-own solution which you cannot afford in the long term. In other words, its momentum.
Astute readers will have observed the clause in the previous paragraph: both beyond and below a certain scale or particularity. A diagram may assist…
Notes
1. domain specificity relates to the uniqueness of the application, scale both to the traffic and the number of pages.
2. the diagram provides no indication as to the distribution of websites across the graph. In reality I expect a good 95% of sites fall into the ‘best done in WordPress’ zone.
3. when I say “grow your own”, I’m not saying boot up BBEdit and begin from scratch, except for the one-off one-pager. You’ll almost certainly be wanting some kind of framework.
Discussion
I’m still of the mindset that if you can produce a site in WordPress without hacking the guts out of it, then you almost certainly should. WordPress has a much friendlier UI, is at least seven times easier to theme and maintain, is better documented, has a shallower learning curve and has a more approachable user community. I ♥ WordPress.
Nevertheless, there’s a point beyond which you shouldn’t travel with WP. Warning flags include: parallel multi-lingual content (drupal’s still no fun with this, but is considerably more mature), multiple distinct content types, particularly where there’s a need to model relationships between content types (well handled in drupal through CCK, views and node-reference) or any significant dependency on complex home-grown plugins.
Bordering the drupal use-case quadrilateral on the non-WP sides we have small scale apps where using drupal is a sledgehammer to crack a nut, highly domain specific apps where you’re not gaining much from its general purpose features (e.g banking sites) and finally ultra-high-demand sites where the system overheads represent a significant barrier to performance (e.g. Facebook).
In between there’s drupal, and, believe me, I don’t like it any more than you people.
Back-end developers (maverick, yes, but conservative also) oft find it a bitter pill, until that is they’re on their fifth or sixth site, at which point they’ll have stopped questioning the premise and the – cough – idiosyncrasies, and will be pleased to have joined the exclusive club of drupal learning curve survivors, with all the additional employability that affords. Repetition is the key to value add here, which is why drupal is currently so much more popular with interactive agencies than with corporate IT departments.
With the back-end developers on board, the only problems you’re going to have to face are from designers, front-end developers, writers, translators, producers and those managers who can’t get beyond look and feel.
Best of luck with that.
