Thoughts on Content Management
Posted by Matt White, Wed Dec 05 21:51:00 UTC 2007
After developing a few custom CMS apps in Rails, and not being entirely happy with the result, I decided to try Drupal out as a base for a content management app. Now, don’t get me wrong, I love Rails. I wish I could only ever develop in rails. But the economic reality is that most of the work we get calls for flexible content management, and the ‘bespoke’ CMS’s that I’ve built in Rails/PHP/ASP.Net over the years leave a lot to be desired… Also, as the Rails community seems to be focused more around app development, few actual dedicated content management apps have surfaced. Radiant CMS is one, but I’m going to give it a bit more time before I try it on a client project. However, reinventing the wheel every time just isn’t efficient enough to justify building the ‘perfect CMS for the situation’, so I decided to try out some of the open-source heavy-hitters.
Joomla
I built a restricted-access membership site for a client that integrated the user database with their internal enterprise system, and I based that site on Joomla 1.5. Naively, I thought that it was better to base the site on the latest and greatest version of the Joomla framework for forward compatibility. This was indeed a benefit during development, though the documentation on custom module development for version 1.5 was very sparse. Joomla 1.5 uses the MVC pattern, which is really quite nice since I’ve done most recent work in Rails with it’s similar MVC pattern. However, I found the development of modules to be a painful process that required lots and lots of poking around in the core modules to see how it ‘should’ be done, due to the lack of proper documentation.
The Joomla community has had quite a bit of drama lately over licensing issues, which has largely halted creation of modules for Joomla 1.5. This has proved to be a major problem for us, since we had recommended Joomla to the client based on it’s large base of available modules. I’m hoping that this issue will burn itself out soon, but so far it’s just another strike against Joomla.
Finally, after using the Joomla admin I’m just not convinced that it’s nearly powerful and flexible enough to do much more than manage a basic website. The permissions system is quite static, and additional modules seem poorly integrated into the interface. Unlike Drupal, where a module can actually modify the behavior of other modules, each module very much stands alone in Joomla. If you don’t like the behavior of the core framework, it’s time to start hacking.
Drupal
So… after building a membership site in Joomla and being very much underwhelmed by the experience, I decided to give Drupal a whirl. The main features that attracted me to Drupal are the (surprise!) development features, as there is a lot of power to be found in the framework.
The default module set is pretty basic. However, when you add Views, CCK, ImageCache, and Services, you have the ability to build feature-rich sites very quickly. I built a site that allows for full content management by the client with integrated flash interface elements pulling data from Drupal via the AMFPHP remoting gateway, all in a very few days, most of which were spent writing the Flash elements and building the theme. Very little time was spent on actual module development, since the flexibility provided by the above modules saved me from coding custom modules.
The most critical thing with Drupal is to learn which modules are essential. Drupal core is functional, but you really need to add modules to make it useful. The CCK (Content Construction Kit) allows you to build nodes (types of content) with arbitrary column types. This allows you to construct node types that match all of your content. The Views module lets you create custom views for your content, including RSS feeds. ImageCache is absolutely fantastic… It allows you to define resizing presets for images that you can then reference in your templates. When an image is called for, it’s resized based on the selected template and cached to disk for subsequent use. Should you change the template, just flush the cache and the process starts again! Finally, though I didn’t use it here, the Services/AMFPHP module is an excellent way to connect Drupal with Flash Remoting. We’ve got another job coming online that I’ll mention here once it’s done that makes use of this.
All of this said, Drupal is not for the faint of heart. You need to approach it with a bit of a hacker mentality to really get the most out of it. I’ve read many comparisons between different CMS options, and one of the most common complaints about Drupal is the varying quality of the modules, the steep learning curve with development, and the less than desirable quality of the Drupal template engine. Many people who complain about these shortfalls find ExpressionEngine an easier CMS to use, due to it’s ease of skinning. However, I’m convinced that if you’re into development and aren’t too concerned with the skinning issues, Drupal offers a very powerful and flexible base with which to start. Drupal is one of the most extensible platforms I’ve seen, and offers many ways to plug into nearly every bit of the system to insert your own custom functionality. This alone is it’s most redeeming feature.
Conclusion
I’m definitely going to keep using Drupal for heavy content-management sites. However, whenever I’m presented with the opportunity to develop an actual web application, I’ll certainly be going back to Rails.