Some guidelines for Drupal data modeling

The freedom that Drupal gives you to easily create content types where you can choose from a wide variety of field types, and combine them in any imaginable number of ways is, to my mind, Drupal's "killer feature". The fact that it's so easy also makes it dangerous. If I had to name one trait that really excellent Drupal sites share, it's a solid data model that aligns with the nature and purpose of the data, and is naturally extendable as the site expands, without resorting to ad-hoc hackish workarounds.

So you've installed Drupal… now what?

When you install Wordpress, it's pretty clear how to get started: in the left menu bar of the admin interface, you can choose between posts and pages, you can manage media, links, and comments, and you can choose to edit the appearance. When you install Drupal, you find yourself staring at a welcome page that suggests you:

  1. Configure your website
  2. Enable additional functionality
  3. Customize your website design
  4. Start posting content

with some inline internal and external links that might be of some use in accomplishing those things.

Drupal jargon explained!

Drupal has a reputation for having a steep learning curve, but I remain convinced that it's largely overstated. Nonetheless, it's true that right from the start the new Drupal user has to contend with documentation that uses unfamiliar, arguably non-intuitive jargon. That said, "What's a node in Drupal?" is a harder question to answer than one might think. Because the pieces of Drupal are usually inter-connected, an easier term to define, like "CCK", depends on the reader understanding what a "node" is.

Subscribe to RSS - Views