Content Management with Drupal

I promised many moons ago to write something about Drupal. I’ve been doing a lot of things with Drupal lately, and perhaps now is as good a time as any others to start sharing some experiences working with Drupal. For those who have not heard about Drupal, it’s a content management system that is supported by a larger number of community contributed add-ons, giving it a plethora of features for just about everything you want (and yet not quite, which is why development still goes on…).

A common problem I see at my work place (and which I’m sure is pretty common in many other places as well) is that a lot of information is not shared effectively and efficiently with the right people. It is either not written down at all, or it is written down somewhere that doesn’t get read. Documentation, which is what I call information that is written down, is often hated by both the writers and the readers. Of course, a content management system is merely a tool, it won’t change things on its own, but it does give people less excuses to avoid writing and reading documentation.

So some time last year, I finally got started to seriously explore revamping the documentation platform we had at work. (Actually, we did not quite have anything that was dignified enough to be called a documentation platform.) Some things that we had explored before then were Wikis. We did actually have Wikis running for a while, but in my opinion, it has been somewhat of a failure. It didn’t quite do what it was needed to do. To start with, it was not fun to use. It did not really help with writing, and if it does not help, people are still not going to write. Tools will not solve people problems. But I believe the right tools can help people get their work done.

After trying out a bunch of the more popular content management systems, I quickly decided to zoom into Drupal to get some in-depth understanding and appreciation of the features it can offer. My first impression of Drupal? It was damn ugly. Yeah, I complained about this before. But I needed to focus on the feature requirements that was important to me. Here’s a condensed list of the most important things that I was looking for:

• Active development community
• Large pool of 3rd party contributed modules/add-ons
• Decent technical documentation available
• A good WYSIWYG editor
• Granular access controls to read/edit content (including ability to do role-based or group-based controls)
• Revision tracking of all content changes (including “diff”-like visual output to identify changed contents)
• Controls over content organization
• Workflow processes
• Theming flexibility (because of corporate “look and feel” requirements)
• Forum, photo, custom content types
• Authentication with RADIUS and LDAP backends

To be honest, I did not actually go about installing a whole bunch of software. It would have been too much effort. For some part, I depended on the demo installations at php.opensourcecms.com, which really gives you a quick test-drive of the various software  without having to do any installation yourself. (If you’re wondering, they also have demo ASP CMS as well, but I chose to go with PHP and not with ASP.NET due to my lack of familiarity with ASP.NET. There aren’t many ASP.NET software anyway.) At the same time, I also did “online research” on the software home pages, 3rd party reviews, etc.

Drupal stood out as being one of the most popular, flexible, and extensible content management systems. But many things cannot be discovered in just 1 week of testing. I have now been running a Drupal site for over 6 months, and I am still discovering new things about it, both good and bad. The extensibility with 3rd party modules are really amazing. There are so many of them. It reminds me of all my development work, including web development work, using the Perl programming language. Perl is an old-time scripting language. There is a Perl module already written to do just about everything you want. In the same way, there’s probably something in Drupal’s rich collection of add-on modules to do something you want.

There is one little thing about Drupal that I was quite impressed with. It’s something most people cannot be bothered with, but it is my pet peeve. Drupal produces XHTML 1.0 Strict compliant code beautifully. Many of the add-on modules also produce compliant code too. This is really great, otherwise I would end up spending a lot of time correcting the XHTML output. I’m quite particular about standards compliance on the web.

One of the downsides with Drupal is the problem with backward compatibility. They have acknowledged that they would sacrifice backward compatibility if it hinders development of new features. This has caused complications trying to grapple with code and modules that are 4.7-compatible, 5.x-compatible or 6.x-compatible (and soon, 7.x-compatible). The numbers refer to the Drupal core version numbers. Many of the add-on modules are available in multiple branches due to the Drupal API compatibility. It is not so much an issue if every module was available for every Drupal API version, but as you can imagine, that is not the case.

Backward compatibility is a difficult thing. I can understand that sometimes you just need to move forward. Many opensource software are cutting edge because they move fast and move swiftly. Sometimes it is inevitable that design choices they made a year or two ago turns out not to be the best choices. Drupal is certainly not the only or even few software suffering from this problem. To their credit, however, the labeling of 4.7-compatibility, 5.x-compatibility, and 6.x-compatibility does help clearly identify code compatibility as Drupal evolves.

Drupal’s flexibility also creates tremendous complications at times, when it is not clearly understood by users (i.e. the site administrators). For example, I ran into a puzzling conflict with access controls. After much code tracing, I eventually unearthed the truth. There are two parts to access controls. One is based on permissions. It has limited extensibility. However, it is very well complemented by “grants”. There can be multiple grants, each configured by a different module. Drupal’s core code ORs the grants together. Sometimes this is not what you want. So a third party module (module_grant) came along to change it to an AND. Cool. Except that some core parts of Drupal continue to retain their OR logic, and this resulted in some “information leakage”.

I wanted the AND logic. But I sort of agreed with the Drupal’s core code that Grants are about granting access, not about denying access. So it makes sense to OR rather than AND. Nevertheless, the most important thing for me is, whether OR or AND, there had better be consistency.

Also, having been spoilt by WordPress ease of plugin updates, I find Drupal’s module updates rather old-fashion and tedious. It gets quite a chore once you have installed a large bunch of modules and find that every now and then something has an update. The Drupal core itself is also quite a hassle to upgrade. The official upgrade instructions are really long-winded, although perhaps some expert users might have realize that some steps are not really needed.

The best thing I’ve been able to get out of Drupal is customizing it to do what I need. The core code doesn’t quite do everything, but with the right mix of add-on modules, some setup, and customization, my Drupal site has been able to accomplish quite a lot of things. The setup does take a bit of effort. But I think the end-results are quite satisfactory.

In my next update on this topic, I’ll share more details about what I’ve done for my site.