Concerns about Drupal Release cycle

In previous posts I preached for Drupal, and I feel I should amend some concerns; the first and foremost is Drupal release cycle.

Drupal major versions are not compatible with each other. They “break the API”. All the contrib modules need rewrite (contrib modules are 3rd party plugins, and you use them extensively). Themes (templates, designs…) need rewrite.

Major releases come, in theory, every year or so. So you have to upgrade you site every year. For me this is a major drawback. I haven’t been through this yet, but I will probably hate it.

There are two major versions supported at any given moment (right now it’s 5 and 6). But you can’t really buy time by skipping major releases (e.g. moving from 4.7 directly to 6). Well, maybe you can, but it’s problematic. One reason is that the official upgrade process is only from the previous version, 5 in this case. More importantly though: you can’t really use Drupal when it’s first released, so there aren’t really two functional version supported at any time.

Drupal 6 (D6) was released on February 2008. At that day, the compatible Views module released an alpha version, and today, we only have a release candidate for Views. I wrote about View in a previous post: it may be a contrib module officially, but I don’t think there are many Drupal installations that don’t use it. And with more peripheral stuff, it may take months before you have a first compatible release. The celebrated Zen theme, for example, only released an initial D6 version in May.

I use D6 for my site, with many modules still in RC, beta or even alpha stages. It’s probably not best practice, and I wouldn’t do it for an enterprise site. Even as such, though, I won’t be able to skip D7: the way I understand it, the day D8 is released, my D6 site won’t be supported anymore, but it will be many months more until I can actually replace it with D8 site.

Now in comparison, Joomla still supports 1.0.x, where 1.0.0 was released in 2005. It’s probably well worth upgrading to 1.5 by now. Yet however painful the upgrade is (I have no idea), once in 3 years it’s not unreasonable.

Drupal developers defend the release cycle fiercely (for example here), and I am not going to argue with people that do good work for me without requiring me to pay. However I think it’s a point well worth considering before you commit yourself to Drupal.

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.

Why I moved from Joomla to Drupal

“Joomla or Drupal” seems to be a question the web asks itself quite often, these being probably the most popular open-source content management systems. So I thought I might add my perspective.

I am not a professional web developer, but in my spare time, and for the sake of the greater good, I have built and am maintaining a congregation web site.

I first moved to CMS-based site more than two years ago. Back then, I decided on Joomla mainly because people said it was much easier to master. I still think it’s true, nut it comes at the price of being much less flexible (which is a trade-off you could expect).

Just an example. Joomla has an extremely annoying categorization system. There are sections, which contain categories, which contain content. Every item must be in a category and every category must be in a section. I can’t suppose the people who designed Joomla were morons, but I do think it’s pretty weird that they thought all the content people would ever want to put into Joomla would fit into this scheme. This is not a very important limitation by itself. I worked with Joomla, I coerced myself and my data into this system, it wasn’t pretty but it worked. I am just saying, people who design like that cannot be expected to build a flexible system in general.

Drupal’s design is much more open-ended, which means things you could not do with Joomla, or you could not reasonable do with Joomla, can be done with Drupal. Also, things that would require you to tinker with your Joomla template or write a new component or module, are done using the web interface only in Drupal. I am going to write more about this in the future.

The other selling point, for me, was the strong support for multilingual sites in Drupal. With Joomla I had two installations to support bilingualism, which means two logins, twice the maintenance, and media files duplication. Building a multilingual website isn’t effortless in Drupal either (maybe I’ll blog a little about that too), but it’s possible and it’s worth it.

I have worked with Joomla for a long time and only migrated to Drupal recently, so I do fear some agonies are still to come. In fact I already have some rants that I will probably share with you at some point. But for the time I am very happy with the move.