Project Spork continues…I’m reporting on my first impressions with Drupal. Short version: It’s confirmation for why I often steer clear of open source solutions.
First, a few words on my previous web development experience. I’ve designed and run several sites mostly the old-fashioned way: hand-coding with a few leanings on development environments like Dreamweaver to quickly build the more complicated dynamic elements. Throughout most of this work, the closest I’ve ever come to using a CMS was integrating tagged WordPress feeds in a way that allowed site owners to publish and edit content to their public sites via a private blog. Aside from the SEO issues this raised, it was a great solution for my non-technical clients.
Since those days, I’ve used a custom-built CMS which was more of a PDF cataloging system for a research portal at Adobe Systems (the shell of that site had to be managed by hand-coding in Dreamweaver); and I’ve been using Serena Collage at my current job, which is half-way between straight hand-coding and the full-on CMS that is Drupal.
If I had to describe Drupal in one word, it would be “patchy.” If you’ve worked with this platform for more than a day, you’ll probably know what I’m talking about. Drupal is built for very, very simple, collaborative sites that are more akin to blogs or wikis than traditional institutional sites. To get it to provide features that act more like applications, you’ll have to deploy those features elsewhere and bring them in through iframes, etc.; or start building up the patches.
The Drupal community calls these patches “modules.” The problem is, because Drupal is an open-source product, these modules are not built with one focused direction in mind as might be the case with a CMS built by a company. Some might call this a strength, since it means that there are modules out there for pretty much any CMS problem that needs a solution. But often these modules rely on one-another to function and sometimes they don’t play nicely together, meaning that a web manager might spend more time trying to troubleshoot module disunion than they might otherwise take to build a custom solution in-house the old-fashioned way.
This was the case with Spork’s Drupal instance.
The problem we faced was re-creating our library hours widget, which is essentially a database-driven application that sits on our library homepage and functions much like the opening hours feature on a Yelp page. If the Library is open, a green OPEN message is displayed; if closed, you get the red CLOSED message. This feature works across our various locations, which often have special opening hours that change around holidays and finals. It also allows users to work with a calendar widget to select date ranges in the future or past.
This is where Drupal started to break down on us.
Building the databases in Drupal 7 is quite easy and I had great success building a tagged set of FAQs that could display only on relevant sections of our Drupal site. No doubt, the hour database would be easy to build, but creating the app and site functionality that made this database pop would require dozens (seriously) of inter-related modules. To add all these modules took significant time to upload and install. When it was all said and done, I still did not have the hours application I was hoping for, but worse, I had a dizzying array of modules imported into my site, which just felt like a administrative nightmare waiting to spring forth at the next Drupal update.
Drupal themes also seemed problematic. These also appeared largely dependent on one’s version and any customizations might be lost if one were to upgrade. Moreover, there were a few themes that did not seem to function all that well. Yeah, I understand that this is open source. But this is also my professional reputation being tied up in someone else’s hobby.
But the real problem I have with Drupal (and this may turn out to be with all CMS), is that I really just want to add code to my sites the old-fashioned way when I need to get something done…and done quick and done well. From my experience thus far, Drupal does not make this part easy and I was actually missing LibGuides and even the broken CMS we currently use.
Case in point, my colleague Jim LeFager was trying to add JQuery functionality to a Drupal page. JQuery is supposed to be integrated in Druapl 7, but it turns out that to get any JQuery to work, you have to include one line of php referencing the JQuery library. Okay, not so hard, except that this critical piece is not documented anywhere. We only discovered it when Jim found a blog entry by someone out there who had run into the same issue.
Really? Is that what we can expect?
Sorry, but for all the hype about Drupal, I’m not sold. The new Views module and CCK integration are great additions for building database-driven sites, but a CMS built for web developers, this is not. There has to be a better way.