Enter the Drupal
After much dithering and review of blog & content management systems, I selected Drupal as the engine for my revised website. Why Drupal? The key reasons are:
- Ease-of-use and large selection of modules & themes
- Excellent categorization of content through taxonomy system
- Nice input filter system that lets me choose the format style (e.g. HTML or Textile) for each entry
- Clean URLs through apache mod_rewrite as well as Drupal URL aliasing system
- Built-in revision system so I can handle different versions, although you can’t mark one revision published while working on another.
- Huge developer community that’s also fairly software savvy
- Written in PHP, and I’m more familiar with that scripting language
Many of these features aren’t exclusive to Drupal. Mambo, for example, is a very slick package right out of the virtual box. It had enough eye candy to get my wife’s vote for her website, and since it was the runner-up in my evaluation, I’ll compare Mambo and Drupal.
Mambo has flashier templates, an option to load demo data during install (great idea), and an incredibly easy download/configure/run install procedure. The nature of Mambo add-ons wasn’t immediately obvious, and it took more work to find stashes of add-ons for download. Mambo has three varieties of add-ons: components, modules, and mambots. I would have renamed components to packages, since that reflects the increased complexity & size of these add-ons; full-blown forums are available as components in the Mambo world. Mambo modules could be called blocks, generally display-centric add-ons that can be positioned on the sides.
In contrast to Mambo’s scheme, Drupal has one type of add-on—a module—and most of the available modules are organized neatly by Drupal version on a Drupal.org download page.
When adding images to a page, Mambo wins hands down with its Images tab which previews pictures and lets you set attributes. The UI is definitely slicker, but sometimes the administrative drop down menus would stop working on my IE 6.0 (and Firefox) browsers.
I looked at systems using PHP (Mambo, XOOPS, Xaraya, WordPress, TextPattern, and others), Perl (MovableType), and Python (Plone). The open source community has created an impressive array of tools, and many of them have packaging & documentation that look as commercial as you’d ever expect from unpaid volunteers.1
After playing around with the admin tools and looking a bit at the underlying code, I think Drupal is the best for me. The URL aliasing (through Drupal’s path module) provides an easy and powerful way of redirecting requests for my old pages. If I want to alter the operation of a module, like hiding the user login box unless I supply a URL flag, it’s easy to find the pertinent code and make changes. And I already mentioned the input filters, which let me chain the content I enter through transformers like Textile. There are some hiccups, like Search not working and some oddness when mapping multiple URLs to a common target.
For my personal website, I want great administrative tools, a good collection of extensions, and a fairly clean look & feel. But for Writertopia, a writing workshop & resource site I’m building, I had additional criteria, including a tailored permissions system and extremely fast prototyping, which pointed me in the direction of Ruby On Rails. I’ll post more on Ruby and Rails as I build a Rails version of Writertopia.
————————-
1 Actually, that last bit was incorrect. There’s a growing number of companies built around open source software. The usual suspects support operating systems and databases, but there’s a fair number that make a living off applications like content management. Zope, the force behind Plone’s core, is a good example.
