Assessing and choosing Drupal

August 30, 2007: by Edward Peters

I’ve spent much of the past 2-3 weeks researching Drupal as a possible CMS for IofC. My research has involved a lot of reading, and also the installation of Drupal, adding modules and trying to build IofC functionality in Drupal. I agree with those who say that Drupal has a steep learning curve; I hope it’s true what people also say - that after a time, once one becomes familiar with Drupal, it becomes easy!

Drupal or Joomla?

If IofC is to go the Open Source route, there seem to be only two possible options – Drupal or Joomla. I have not installed and played around with Joomla to any extent. But I have done some reading on it. The conclusion is that Joomla has some advantages, and Drupal has other advantages. It all comes down to what is most important for us – neither product will give us the best of all worlds. A not very recent comparison can be found at This was written before the launch of Drupal 5 (now stable) and Joomla 1.5 (not yet stable, but likely to be a big step forward).

An independent assessment done for the Canadian Union of Public Employees (CUPE) is available at; it makes a clear recommendation in favour of Drupal, because of Drupal’s better multisite and multilingual functionality.

Joomla is more commercially oriented, and has more of a commercial development community. Drupal is more fully open source, and it can be harder to find commercial developers for it.

What I have read indicates that Drupal is better in ‘architecture’ and Joomla better in most ‘functionality’. One developer writes: “As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything.”

My view based on what I have so far discovered is that Drupal is a better option for us than Joomla.


This is a core requirement for IofC. In Drupal release 5 there is no core support for multilingual content (this can be achieved by adding the i18n module, but it is limited). In Drupal 6 much of the i18n functionality is built into the core, and it is being seen as a big advance. See for

I have experimented with multilingual content, and it works quite well, including the translation flow. However, I ran into a problem with Views (the module that creates dynamic lists of content) and could not get it to work well with multilingual content. I could save views as blocks and then add them to pages, but the Page View mode did not work properly. I think there may be some compatibility issues between the i18n and Views modules. The Views module is being completely rewritten for Drupal 6, so we may find big improvements - and at the very least no compatibility problems.


This is another core requirement for IofC. We have yet to be satisfied that this can be achieved properly. But all I have read about Drupal makes me fairly confident that it can be done. The assessment done for CUPE (referred to above) specifically mentions Drupal’s multisite capability as a core strength for an organisation like CUPE which needs hundreds of small local websites for its members.

There are likely to be more than one way of achieving this, and we will need technical advice on the best way. We have to be sure we can achieve multisite functionality, before we go too much further.


This system of being able to classify and categories almost all types of data is very powerful and gives us great scope for major functionality.


These are powerful, but take some work to understand. In a multisite environment, page templates are stored by site. I think we will be able to customise look and feel as we have done in our interim system, though it will work differently. Some aspects may be more powerful than in our system (e.g. you can have templates for different nodes and for different users), while other aspects may be less powerful than ours.

Contacts, virtual databases, users, groups and security

From my limited exploration of CiviCRM, I think that it will handle most of our needs, but I have not gone deeply into this.

Many things are simple in Drupal

As I have gone along I have been impressed by how much Drupal can do without any programming. Some of it is big and some of it is just little but valuable things. A few brief examples (there are many more):

  • Interface translations come all ready for many languages.
  • RTL (right to left) text easily accommodated.
  • Translation flows.
  • Comment/feedback forms can be attached to any node – both as a default setting for a content type, but also overridden for individual nodes.
  • Forums work well with minimal tweaking.
  • Blogs are built in to the system.
  • Creation and placement of dynamic data sets is excellent through the Views module.
  • Excellent user customisation functionality.
  • RSS built in.
  • Logging is very good.
  • Excellent developer/debugging/system tools.
  • Collaborative tools like Book authoring built in.
  • Cross-browser compatibility, and accessibility standards.
  • Good security.

But we will have to make sacrifices if we use Drupal

There is no getting away from the fact that we will not get very close to our ideal CMS functionality if we use Drupal. With our proprietary system we can achieve just about anything we want, but with Drupal we will have to sacrifice some of our ideas. In particular I think we will have to modify our hopes with regard to:

  • Our proprietary system of blocks which can be shared. Drupal works in a different way.
  • Sharing of ‘articles’. This is going to be harder to achieve in Drupal. We may possibly even have to abandon it altogether.
  • Enforcing one occurrence of URLs through a database table. It may not be impossible to programme this but it could be difficult.
  • Multilingual caption system for photos. I am not sure yet, but if we use Gallery2 we may have to settle for one caption with each photo – but then allowing editors to add a dedicated caption when placing a photo.
  • The user/group system is unlikely to be as good as the one we have at present.
  • Document management is not great at present, but new modules may be coming.

Weighing it all up

For most of the past three weeks I have been leaning heavily towards Drupal. But, as I have become more aware of the limitations it will place on us, I have remained open to the idea of continuing our proprietary system. To go that route would see us with a product which would undoubtedly be closer to our ideal in many areas. But it too would involve considerable compromises as we could not expect to develop all the interactive Web 2.0 features we want, nor keep up with the new developments that are unfolding all the time in the world of the web.

Going with Drupal will mean sacrificing some of our ideas, but it will mean embracing many good new ones. It will give us significant advantages in terms of adherence to standards, access to core functionality which is time-consuming to programme, participation in a worldwide community of developers, and the capacity to stay close to the leading edge of web development.

My recommendation

It is clear to me that Drupal is not going to meet all our needs. But rather than focusing on what we will lack, I think we should focus on what we will gain. Let’s embrace Drupal and create an IofC framework and online community which utilises its strengths.

APPENDIX: Websites using Drupal

A full inventory of Drupal powered sites is at The following sites are among those which use Drupal and can give us some confidence that we can achieve what we need:

Amnesty International is apparently rebuilding its sites and CMS using Drupal.