A few months ago, I made a post about choosing a CMS. At that time, we were utilizing several different content management systems depending on project complexity and client preference. Since then, however, we have switched exclusively to Drupal as our CMS of choice, and in this post I will explain why.

A Real World Example

We are currently working on a website redevelopment project for the American Society of Media Photographers (new site will launch in early summer ‘09). In addition to requiring a full range of content management features, the project had three requirements that were a bit outside the normal range of a CMS project:

1. Authentication against an existing, proprietary user database
2. Integration of existing PHP code into Drupal, preventing the need to re-code entire site features that already worked as standalone components
3. The ability for chapters around the country to manage their own sub-sites on the main ASMP site

Obviously, we did our homework before settling on a CMS platform. The first thing to realize about Drupal is that it offers a truly granular level of control over the entire system. Here at Context, we’re generally fans of fully object-oriented MVC architecture. Every custom PHP project we do is built on top of Fuse, and we lean heavily toward Magento as our E-Commerce platform of choice. Drupal, however, is not MVC driven, nor is it generally object-oriented. However, the hooks system is extremely well documented and well integrated, and it allowed us to hook directly into the authentication functions to make short work of item #1 above.

Next, a mix of the PHP evaluator module and the PHP path module allowed us to simply ‘include’ existing PHP files at URLs of our choosing, and surround them in the Drupal page layout. We removed & replaced the page styling on the legacy pages with the updated CSS (and also removed the header and footer), and found that we had the legacy code transparently working within the Drupal structure.

Finally, #3 – chapter sub-sites. Initially I had thought we would need to develop a custom module or make heavy use of Taxonomy to tackle this one, but the Domain Access module provided a much more comprehensive solution. Built specifically for the management of sub-sites, we were able to integrate it into our Drupal install and get moving right away on managing sub-sites.

Why NOT Drupal?

So, we all know that Drupal is extremely powerful, but what keeps developers consistently choosing other open source content management systems? Previously, I felt that due to Drupal’s complexity and learning curve, it should be reserved for larger scale projects that really require its power. Otherwise, I thought, maybe it would be best to just put together something in WordPress, Joomla, or ExpressionEngine. However, Drupal’s bark is bigger than its bite when it comes to the actual learning curve, even for the more powerful and complex fatures. Drupal is certainly set up a bit differently than other content management systems, since it lacks the user friendly admin dashboard we’ve come to expect from Joomla, WordPress, or EE. Additionally, the Drupal default install is quite unimpressive. You have very little functionality until you start installing modules, and some of the terminology and information architecture can be a bit confusing at first. But just hang in there. Everything starts to make a lot of sense once you start delving into the system, and from there you will be “hooked”. Having a good book doesn’t hurt either – we liked Pro Drupal Development and Learning Drupal 6 Module Development .

So, at least for a while, it’s Drupal for us as our CMS of choice for any size project. I’m interested in seeing what Joomla does with version 1.6 (granular user permissions, finally), but I have to admit that I’m considerably more excited about Drupal 7.