In presentations I usually point out that Drupal is three things:

1. A content management system: The forms you fill out, the buttons you click, and the content you work with. The stuff you interact with every day while you manage your site.
2. A content management framework: The low-level APIs that let you extend and modify Drupal to make it do everything from ratings to image galleries to your dishes.
3. A community: The thousands of documentation writers, developers, testers, support providers, designers, and evangelists from all over the world, working together to make Drupal a better platform every single day.

It's this third point I'd like to talk a little more about today, by providing some insights into the general Drupal community philosophies that guide our interactions with one another, and as a result, the growth and direction of the Drupal project as a whole.

The Drupal community has several core philosophies, some of which are documented, others of which you just kind of pick up from spending enough time watching various interactions on the forums, on issue queues, and on the mailing lists. Here's a brief guide, for the uninitiated.

I recently evaluated ExpressionEngine for viability as a CMS replacement for Drupal. ExpressionEngine (EE) is a commercial CMS tool built on PHP and mySQL by EllisLab. A client of ours was attracted to its clean interface, built-in features, and expandability.

I was impressed by the well-designed UI and the flexibility of EE's templating engine. There are definitely lessons the Drupal community can learn from their attention to detail. In fact, as I explored the EE support forums, I discovered a great deal of antagonism towards Drupal -- to my surprise, it wasn't based on features or learning curve, but on the idea that Drupal is insecure.

In the forums, comments such as this were common whenever Drupal or other CMS systems were brought up for comparison:

Some reasons why one might not want to use Drupal?

[2/5] Drupal Acidfree Module “node titles” SQL Injection Vulnerability
[2/5] Drupal Unspecified Spoofing Weakness and Cross-Site Scripting

Various attempts at "fingerprinting" a Drupal site have been tried in the past, none of which are completely fool-proof.

These range from *super* easy stuff like checking for CHANGELOG.txt to checking the source for a reference to "drupal.css" (Drupal 4.7) to checking for common paths like taxonomy/term/1, and /user, (which might be aliased to something else with something like Pathauto/Path Redirect module), and so on.

However, since Drupal 4.6, there's a super geeky trick you can use to fingerprint a Drupal site that works 90% of the time.

1. Get Firefox.
2. Get the Live HTTP Headers extension.
3. After restarting Firefox, click Tools > Live HTTP Headers. This'll pop up a little window to the side.
4. Visit a website you suspect of being Drupalish. You know, like http://drupal.org/ (except, you know, I bet they're running WordPress...).
5. Highlight the Live HTTP headers window and type "exp", looking for the following in the output:
   Expires: Sun, 19 Nov 1978 05:00:00 GMT
   You know, like so!
   

Update 2008-May-31 Or! For you command-line junkies out there, check out TBarregren's helpful bash script which allows you to just do ./is-drupal www.lullabot.com - Awesome!

By the way, this date has special significance in the Drupal community. Anyone know why? ;)

Hat tip to chx for this trick. :)

Drupal has a lot of forms to fill out and not all of them may be just the way you want or need them to be. Modifying forms is a topic that is often met with groans but once you understand the two methods to accomplish the task and the basic, underlying concepts, it really isn't that hard to do at all. You'll be a form-modifying, input-customizing wiz in no time. This article will briefly discuss what's going on and then mainly focus on showing working examples for both methods in Drupal 5 and 6. You should be comfortable creating a new function, looking at arrays and a having at least a passing understanding of the Forms API is real handy. Also note that in the examples below I have them wrapped in php tags but you should not include those if you copy/paste. That is just so it looks nice and clear for the article.

Deciding to make the change in the theme or a module

So there are two methods for altering form output in Drupal, one at the theme layer and the other through a custom module. Changes to the HTML can be accomplished with either method so most people will use the method they are more comfortable with already; themers use the theme and developers use a module. There are two situations however where you will want to use a module rather than a theme:

1. Changing functionality of a form (e.g. adding new validation rules or submission actions) can only happen in a module.

During a recent Lullboat podcast we mentioned a new feature in Drupal 6 that allows you replace any string in Drupal without using Locale module (thanks Moshe!). Faithful podcast listener Rob Loach took it upon himself to write the String Overrides module that lets you accomplish this task with ease in Drupal 6.

While Lullabots were lamenting the fact that this feature was never in Drupal 5, we realized that it actually could be accomplished. An hour after undertaking the project, the patch was submitted to the String Overrides queue and committed shortly afterwards.

String Overrides accomplishes this in Drupal 5 by imitating the Locale module, and without hitting the database (since variables are cached and pulled up on every request anyway). Since this essentially a hack for Drupal 5, you cannot combine it with Locale module or languages other than English. Here's the key code that makes this possible: