Intro to Drupal

Lately I’ve been working on a few Drupal projects.  Accordingly I’ve seen much of what Drupal can and can’t do.  Here’s some info to help spread the word on Drupal:

What is Drupal?
Drupal is an open-source CMS (Content Management System) which is written in PHP and uses a MySQL or PostgreSQL database as a back-end.

What’s good about Drupal?
Drupal is architeced with two major components, modules and themes.  The logic of a Drupal site is basically defined by a collection of modules which hook into a small central “framework” (the quotes are there for a reason, more on that later).  Themes accordingly describe the look and feel of a Drupal site.  The benefit of this design is that it is easy to modify and extend the capabilities of a Drupal site simply by installing new or replacing existing modules or themes.  To obtain new modules or themes the Drupal community has a large repository of pre-built modules and themes which you can generally download and install.  Additionally it fairly easy for most PHP programmers to create new or modify existing modules and themes.  All of the code Drupal “framework” and base modules are well documented.

What’s not so good about Drupal?
As a CMS Drupal has a problem that many open-source projects share, intentionally or not Drupal is geared to the Linux/PHP geek crowd.  An average user could probably get out of the box Drupal running and get a basic site setup, anything beyond this however most users will hit a wall.  They will find themselves surrounded by a collection of complex and confusing features which may require configuration or customization outside of the web administration interface.  Now this is by no means a fatal flaw but it is something to keep in mind when trying to decide if Drupal is appropriate for a project.
Another problem I’ve faced with Drupal is that many of Drupal‘s core modules and community contributed modules are more limited than they seem.  This is primarily experienced from a developer’s perspective.  Frequently a developer will start to work with a module or function (i.e. Drupal’s Forms API) and eventually they will be backed into a corner where they will be forced to either modify core Drupal (obviously undesireble) or to re-write the functionality from scratch.  This can be extremely time consuming and frustrating.
A final problem I’ve faced with Drupal isn’t necessarily a problem with Drupal itself but instead with how people (developers) perceive and use Drupal.  Many Drupal developers view and treat Drupal as a web application framework, this is unfortunate and problematic.  Read on to my next question for more details on this problem.

Isn’t Drupal more than a CMS, isn’t it a Web Application Framework?
While Drupal “feels” like a web application framework I would argue that it is not.  The main reason I say that Drupal is not an application framework is that an overwhelming majority of the time Drupal formats content instead of models data.  What’s the difference you may ask?  Formatting content generally means that you simply trim or style a piece of data which may or may not have its own internal structure.  When formatting content very little is actually known about this internal structure.  Modeling data however breaks data down into its most basic parts and then rebuilds the data by defining the data’s internal structure.  Thanks to this key difference one tends to run into many limitations when they try to use Drupal as an application framework.  Basically once you need to access or modify your data’s internal structure you’ve hit a wall you cannot cross (at least not without making fundamental changes to the application).

So what is Drupal best suited for?
The ideal situation for Drupal is where an experienced programmer or company creates a custom (relatively static) website for a non-technical customer.  Leveraging Drupal‘s module and themeing capabilties the prorgrammer can quickly create the site as well as a customized managment interface for the customer to use.  In this situation the complexity created by Drupal‘s extreme flexibilty can be handled by the developer (ideally) leaving an easy to manage, custom website for the client.

~ by seanoc on October 9, 2007.