Comparing Drupal and Joomla for Digital Publishing needs

At Thompson, we use a couple of platforms and technologies for our publishing needs. We have a custom built-from-scratch JSP site where we host a lot of our online content. We found that while this worked very well for some of our needs, for others we were re-inventing the wheel somewhat. So we started looking into CMSs. In the open source options, we looked at Joomla and Drupal among a lot of others and I get asked this question a lot - why Drupal and why not Joomla. Some people ask - why keep the custom built JSP platform when Drupal works for you (or vice-versa). I think this is a very interesting question and my answer to this really is that we havent felt the need to restrict ourselves to one platform. Our choice of web platform depends on the product needs and we use back end web services to tie up our infrastructure, syndicate data sources which more than makes up for having to deal with multiple platforms.

Using a CMS really cuts down the time to market for our online products from few months to weeks. We are able to follow industry standard practices in design templating (or theming), our editors are extremely happy because they feel empowered to add content anytime they want and the sites really help with stuff like SEO etc. We have developed custom Drupal modules which embed Thompson's business logic for marketing and operational analytics. We also developed custom modules to work with our digital content formats. The sort of customizations we wanted to do and the control we wanted over how these sites work - Drupal has really paid off there. I am not sure if Joomla has the architecture to allow for these customizations easily. In addition we turned on a lot of back end database syndication between our Drupal sites which allows us to create content once and expose slices of that content in different places.

The only module we have had a lot of trouble with lately is the CA (Conditional Actions) module and its interdependency with unix cron. The trouble with cron dependent tasks is that you never really know whats going on with them and its sometimes too late to find out. For example, the email reminders we set up to be sent to subscribers used to sometimes fail. While we did find the cause and fixed the issue, it was hard to discover and keep track of these reminders.

While using a CMS is great from reducing the development costs involved, it also means that you always follow certain rules, patterns and practices while implementing or changing functionality. So you do loose control somewhat compared to having written the whole site from scratch. Sometimes there can be module interactions you may not predict and the CMS could be doing more than what you need (I noticed on an online service I joined that the site was sending me role expiration notices - something the Drupal admin of the site failed to turn off). So make sure you fully understand what each module does and what it is supposed to do based on your requirements. Making the least amount of assumptions helps...

The Book Module in Drupal

When I found that this module exists I was pretty excited. As an online publisher this would really fit with a lot of traditional content which we were digitizing.

The Drupal Book module may sound very sophisticated, but all it does is take the individual Drupal nodes which are part of the book and it relates them to each other (parent/child/sibling etc). Sort of puts an order into the system. This turns a random collection of pages into a book. Looks neat and sounds cool. The devil is in the details.

We have been playing around with the Book module and found that from a workflow standpoint, it has both pluses and minuses. Let me explain....

We maintain all our digital content - books is what I am talking about here in the DocBook format. These are books written originally for the paper format, maintained in tools like InDesign/InCopy or PDF/Word etc. Some may debate that DocBook is not a format etc and technically that is true, but for our discussion here, lets just call it a format to make it easy to understand. Docbook is a special XML format which preserves the structure, feature and content in the book w/o its style information. A DocBook file can then be converted to PDF, any form of HTML etc by using XSL (XML stylesheets). You can see I am laying it down here in the most layman language I can ;).

The Drupal nodes on the other hand all exist in the Drupal Database. The page text of each page in the book is stored in a text blob field part of the node. This is all HTML.

So what you would do is take the DocBook version of the book, say "Advanced Guide to Drupal" and write a script to import the different pieces into the Drupal database as nodes, simultaneously creating the relationships between these nodes so they get the book structure (Drupal uses Book Page for this, but that is just semantics). There are myriad of issues with things like footnotes, diagrams - but that is all fun stuff you will encounter and fix.

The advantage is that your book and each page of it separately is in the database. If you want you can ask the editor to directly edit the book using the Drupal Admin Interface which I am sure they will like. However if you are in the same position I am, the update will probably come in the paper format first and then you go through the process of conversion to DocBook to get a new version of the book. Note - I said "book" and not the "update". When you get the complete book, there is no marking there to identify what has changed. Then you delete the previous instance of the Drupal book in the database and load this new one. You must have path aliases and clean URLs configured else the URLs will keep changing on you (since the node numbers change each time you do the upload).

The drawback is that it is hard to point out to the user what is changed unless a separate document is loaded in the system. That's what we are doing now. The other drawback is that since you are loading/unloading the database, the script takes time to run. The search engine may also need to re-index.

Since the book is in the database, you could tag the book pages and do a lot of other fancy stuff. I am still waiting to do that though - the bang for buck!

Set up your own Drupal best practices

Once you do a couple of Druapal sites, you will realize that you are doing the same things again and again thinking each time how they are done. I think Drupal has something called installation profiles and this may be something to tinker with (I haven't). However what I am talking about here probably goes a bit further - each module you install must not only be configured but also styled in some consistent way. Especially shopping carts and any other payment pages which may not vary too much between sites. Having a best practices approach with some documetation may be a good idea if you have more than few people wokring on the project. We use SVN so even checkin/checkout/export/import of modules have best practices which must be followed or you will be repeating the same mistakes and forgotten steps over and over again. Here are some of things you can document in a BCP:

1) Which modules need to be installed and how they should be configured.
2) Style guidelines. E.g shopping carts have rules for which colors typically are used in what places and how the flow needs to be, where the coupon code needs to be placed relative to the product pricing and how they need to be set up.
3) Which roles need to exist and how the permission system needs to be created to satisfy operational needs

These crazy Drupal modules

Before we started using Drupal, I read in a lot of places that Drupal has a module for everything. I sort of believed it - what could we possibly want to do on the sites which many others haven't done already. After about 6-8 months of building site after site I realized we were customizing Drupal a lot and even wrote a couple of new modules - some simple and others very complex. Now almost a year into this, I can re-affirm that Drupal does seem to have a module for almost anything you have seen on more than a few sites. This really helped reduce the time to market for our products from months to days. The best part was that once you set up the system a couple of times, it becomes a relatively repeatable process with predictable results. The common administration end for all the sites (which you almost never ever have to change) is something our team got to be familiar with and now they ask for the same functionality on our older sites as well.

First test post on Drupal

I have been trying to find some time to blog on Drupal and how we are using it to publish web content. Finally, it looks like I made it before Memorial day this year and as a starting post, let me tell you about why this blog is going to turn out a little different from all the other wonderful Drupal blogs out there (which I go to all the time). This blog is about how we are enabling ourselves using Drupal of course to publish and maintain a whole bunch of content sites. These sites go from http://www.schoolgrants2009.com, http://www.grantsinfocenter.com, http://compliance.thompson.com, http://www.smarthrmanager.com and many more. These sites all have a common theme: it is paid content they are after and the focus is a variety of niche markets. The nature of the content ranges from simple news blurbs to some heavy duty analysis of the problems faced by professionals in each one of their individual markets. Our focus has been to make these sites as SEO friendly as possible and make the content easy to find and read. In addition we also strive to make the sites as easy to manage and maintain as possible given the size of the markets and the multitude of sites necessary to make the financial models work.

In this blog I also invite readers to tell us about their similar experiences or suggestions we can use to improve upon what we have so far. I would also try to answer any questions about how we did certain things as best as I can...