Drupal flexibility in four keywords

If you are into CMS choosing, you may have heard (for example in my previous post) that Drupal was flexible. And maybe you think, gee, that’s sounds cool, except I am not really sure what it means. So now I am going to attempt to write about four major flexibility aspects of Drupal, in a language you should understand even before you started the infamous Drupal learning curve.

A disclaimer. As I stated before, I moved to Drupal from Joomla, so it’s against Joomla capabilities, specifically Joomla 1.0.x capabilities, that I compare.

Starting with nodes, then. Nodes are Drupal content items. What’s great about them is that they can contain anything: including full HTML or PHP. I have an event calendar that uses a Google Calendar iframe. It’s just a normal content item that contains the iframe code I copied & pasted from Google. In Joomla, I had to install a component to do that.

Next keyword: blocks. Blocks are boxes that you configure using Drupal web interface. They can contain any type of content (again, HTML, PHP, and see also later about Views), and they can be placed in a bunch of different page location, on all the pages or some of the pages, for all users or some users. So here again you use the web interface to can create stuff that would require a module in Joomla. Back to the calendar example, I have got a list of upcoming events on my homepage. It’s PHP code, adapted from James Cridland, and put into a block that appears only on the front page.

Third, CCK, or Content Creation Kit for long. It’s a contrib module, which means a 3rd party plugin, but I don’t think there are many Drupal installations without CCK.  With CCK, you can create new node types, or content types, and\or attach new fields to existing content types.

Here’s a fairly basic example. The content on my site comes from many authors, but there’s a single person responsible for putting it online (and that’s me). So while the actual author is Rabbi Stacey Blank, the author field can only contain something like webmaster. In Joomla, there’s a built-in solution for that: an author alias field. In Drupal? No problem, I just added the field to the relevant node types using CCK.

Less trivial example? Creating an e-shop without a specialized module, by defining a node type for products. With an e-shop module, your products will have the properties the module author came up with (name, price, maybe size, maybe color). With CCK, your products will have exactly the properties you need (nutritional value? scent? you name it).  Or maybe you need something that just doesn’t have a module, a pets site, a recipes site, a knitting patterns site. With CCK, you can make them without writing code.

Last and certainly not least: Views. Views is yet another omnipresent contrib module. It allows you to query the content items database, using a nice UI rather than SQL, and then put the results in pages, or blocks, or feeds, or wherever. You can use it to create a “last updates” box, or a blog style monthly archive, or random image box. Again, it saves you the need of finding and learning specialized modules (not to mention finding out their limitations and learning to hate them). More importantly, it allows you to come up with original uses to suite your own needs.

As a wrap-up, what flexibility means to me, is that you can create something new, something that the developers of the CMS didn’t anticipate, without having to write code yourself.  And I think Drupal does a very good job on that.