Maintaining web pages, content and special media types can become a huge time sink. This is especially true when everything is done in pure HTML. Using a design tool helps initially but maintaining content, revisions, file uploads, etc. becomes almost impossible with such a tool. In theory CMS (Content management system) rescues us from all of that. In practice a CMS really provides a platform allowing the site administrator and users to focus on content first and worry about presentation a bit later.

There are many excellent CMS available and they are very powerful. I considered ezPublish, Typo3, Drupal, Mambo, WebGui, Plone, TiWiki and a bunch of others. I evaluated them for their core capabilities, extensions, access control security and general ease of use. The problem is that none of them seemed a good fit for us. Either they had excellent access and security controls (Plone/Zope) but had huge learning curves or were simple to learn and use but lacked deeper security (Drupal).

I considered creating my own CMS, and the more I looked at other CMSsthe more tempting it became. But I deciding that I had other projectsthat were a lot more and that the CMS market really didn’t need anotherplatform. My goal became which package could I live with and possibleextend as needed. Of all the CMS packages I examined two stood out themost, Drupal and Plone.

Drupal and Plone approach CMS very differently. Drupal is community driven at its core. Access control is not fine grained and control over access to content is limited. Control over file downloads is non-existent. It was designed as a base for creating community shared sites so access control was never a priority. The community that supports Drupal, possible because of its community focus, is extraordinary. There are extensions for multiple types on content and even some extensions to help resolve access control (limited).

Plone is built on Zope and is really a CMS platform. Out of the box Plone can be used for a CMS but it is a bit clunky. It is harder to set up than Drupal (but not significantly so) but for that effort provides a platform for building robust and powerful corporate sites. Note the focus on corporate. Plone inherits, and extends, Zope’s core security providing strict controls who, what, where and even when. Complex work flows and permissions are easily accomplished in Plone. The downside is that most Plone developers appear to be corporate focused and the extensions made for Plone reflect that. The image gallery, blogs and wikis are all behind the level of Drupal’s modules.

Extending these packages is also quite a different experience. Drupal is relatively easy since it is a number of scripts loosely connected via an API to a shared database. The code is PHP and there is no object oriented nature to the design. The upside is that is is very easy to create a module or hack the existing code to accomplish what you need to do. In general Drupal is fun to extend (discounting for the moment the annoyances of PHP). Plone on the other hand is a development environment. To make a major modification requires a huge learning curve (think Archetypes) and the investment of a lot of time. Plone is not nearly as fun to extend (although Python is a much more pleasant language than PHP for an old Perl hacker like me). The reward is a power customized site that can do anything you desire.

So what’s an engineer to do? Go with the easy and fun yet security limited Drupal, or the powerful more corporate style of Plone? The answer came when I looked at my existing web site. It is a static page that I haven’t updated in years. I have tons of code and configuration notes pending but never seem to get the time to post them to static pages. I needed to change the site now. Thus I choose Drupal. Out of the box it serves pages 3x faster than Plone and with less overhead. Plone/Zope can be cached and optimized to perform well but that requires yet more time.

So in the end it was time and my frustration that caused me to choose Drupal. But Drupal’s lack of strong access control concerns me greatly and I will continue playing with Plone. I suspect someday Drupal will handle security better or I will migrate content to Plone. I am not concerned with migrating content since I suspect no mater what system I choose I will be altering it in 2-3 years anyway.