Drupal 5.x Critique and Thoughts
comments | Posted in php | thoughts on Tuesday, October 16 2007 22:39:00 PDT

Below is a brief listing of current project details I am developing using Drupal. Feel free to correct or comment on any items seen herein.

Types of Drupal Coversions and Creations

I have been developing with Drupal for the last 3-4 months. I have worked on Drupal Installations with the following properties:

  • migrate an existing proprietary DB structure with ~10k of articles and ~40k of images into Drupal hand-coding node insertion thru custom php scripts and Drupal API calls.
  • migrating 12 static filesystem based websites to be powered by 1 Drupal installation.
  • Ported a classic php driven template website into Drupal.
  • Empowering my friends that play WoW with a simple guild website driven by Drupal. [ugg ... world of warcraft, I feel tainted] in which I turned on the key and let them design the look and feel of the site and its contents [I do not play wow].

These works are either in-progress, or at the least for client privacy currently undisclosed. In short, I'm an active web developer who uses Drupal [currently] in his day to day affairs.

The levels of Drupal Interactions and Experiences I have Had

I have dipped into the various layers of Drupal in creating these projects:

  • Customizing the layout and design of the front-facing site
  • adding/creating custom content types for use by users with a Role of Editor
  • importing raw data into drupal
  • Creating custom output for various content types.
  • installing/researching Drupal module components

Drupal Pros

  1. Sane DB Structure for content seperation (nodes) and internationalization.
  2. decent Hook System to alter Drupal's default behaviors. [Something about traffic congestions at freeway on-ramps and off-ramps still makes me queasy regarding this ... but in brief thought I dont have a better solution]
  3. High level module system with simple code architecture [typically 1 mammoth file and 1 description file]
  4. High level custom UI creation capabilities [blocks, views, panels, various allowed kinds of template files, function overrides]
  5. Modules a plenty for customization of Drupal without re-inventing the wheel.
  6. Active, On-going Development with turn around time between major releases at about 1 to 1.5 years.

Current Drupal 5.x Woes

  1. Near broken JS usage. jQuery is nice, but the initial implementation within Drupal 4.7 and widespread usage of 5.x has 1 HUGE snafu. The core developers failed to enforce the use of namespaces within Core or 3rd party modules which have jQuery usage:
  • Drupal's jQuery should play nice with MooTools, Prototype and all other JS Frameworks out of the box. As a developer I should be able to take my favorite open source JS-enabled slideshow, charting, gallery, todo-list applications drop them into a drupal Page (a built in content type) and have them work.
    • This jQuery DOC page: Using jQuery with other libraries created on January 25, 2007 shows jQuery has a mechanism to allow for cross framework mixing in a single web application.
    • This Drupal Core Ticket Issue shows in Aug 2007 a solution was posed to add a top-level namespace to Drupals default JS installation. Which has been slated for Drupal 7 consumption. A 1 year wait to play safe with other JS libraries!?
      • This ticket also has a comment — that this looks like a step back. That scares me somewhat. Core developers not understanding how to safely place your js code into a namespace is akin to not understanding that polluting PHPs global space is bad. We have coding standards for PHP (followed well for the server-side php code Drupal is empowered by). Why weren't similar proper programming standards imposed for client-side js usage? ... So I'm busted on using myriads of other software components because people didn't know how to safely code js. Unless I fix various Core and Theme files by hand.
  1. Drupals various mechanisms for creating "Views", its great there are many ways but seeing how these features have evolved over time has made knowing the best way to achieve your desired view somewhat clunky and almost miraculous when its finally in place. Views makes generating simple blocks easy [its an inituative point and click interface]. But if you want your site to feel non-Drupal-like you have to create override functions to output html which you desire and not the default canned stuff. So its a dilemnia at times to say: Do I make it from scratch, or use Views as a starter. Generating views with: .tpl files, function overrides and core drupal-generated html is confusing. A designer should be able to create the look and feel of the site and need not know PHP to create custom html for a View.
  • Good luck editing Drupal 5.x Menu CSS and layout.
    • This Google Tech Talk: Drupal says Drupal is not really at version 5 its at version 12. Somehow people have lived with this broken Menu css themeing capabilities and other poor useability issues for that many revisions of a codebase. That is not very comforting. Tooling a Drupal page is 1 thing. Designing is another, a web developer should not have a guru at both to get the lookandfeel and behavoir they want.
    • The Views module is not a query builder, calling it such is such a misnomer. Please don't call it that. There is little room for any complex SQL in Views 1.x. Perhaps we will see that functionality in the unreleased Views 2.x. You can make a list of items and sort them. You cannot generate derived tables in a custom SQL query seeking the max() of aggregate fiscal income and extract a truly customized view. So far as I know thru the default Views admin interface, you just can't do that.
  1. No bonified Asset Management. Look at Joomla or Mambo (two other popular PHP based CMSs) and you see that they both have asset management built into the CMS. A large scale CMS should track not only the data-content of a website, but the external assets like images and other forms of media.

Overall Feeling

Drupal still has leaps and bounds to go before it handles content and asset management well. As its evolving hopefully an easier way to generate page areas is found and the current swiss-army knife approach to making pages is made more cohesive for developers and designers. This is perhaps the 1 big drawback from Drupal not being very MVC architechured. I cant just goto a Model in 1 place and request my data and lay it out as I see fit.

I think that overall Drupal is a pleasure to get setup and using "out of the box" and get screens up for your site [which will feel Drupal-ish]. A far amount of [sometimes convoluted] has to go into a site to make it not feel like a cookie-cut Drupal site. Hopefully Drupal 6 and Drupal 7 address some of these issues. But, as it stands with the current stable release these issues are un-resolved.

addenda

  • I am aware that Drupal 6 has helped to address some of the issues regarding menu components and css skinning
blog comments powered by Disqus