Introduction and Background

This first section provides an introduction to this project, and some background information on why IofC has begun working with Drupal. It briefly surveys the history of IofC web development, how we reached a crossroads in thinking about the future, and how we came to the decision to switch to Drupal.

About the IofC family of websites

To understand our project you need to understand a little about the sites which are currently part of the 'family' of IofC sites. At time of writing (October 2007) they consist of 15 or so 'public' websites and one 'private' site for IofC activists, which we call the Extranet. All these sites apart from the Extranet share a backend and run off the same two mysql databases. A unique ID 'webuser' identifies all content so that all content can be shared across all sites.

The public sites are grouped into:

You can see that these sites share branding features, in most cases, though some look quite different.

All major content can be placed onto any of the sites (news stories, etc).

Furthermore the contact data used for these sites (email forms, etc) is taken from one data set which is used for the IofC contact database, integrated into the user info for users of the Extranet.

Our proprietary system (although unfinished) works relatively well. So why have we decided to move into Drupal?

Read on.....!

Why we decided to switch to Open Source

For over five years the IofC web team has been trying to develop an integrated content management system to meet the varied web and internet needs of this global network.

The first iteration (achieved in 2003) was a standalone Extranet (member) website, and several public standalone sites.

The second iteration (achieved in 2005) was the integration of all the public websites into one database infrastructure – with major benefits in content sharing and in speed of new site development.

The third iteration (on which we were working since 2005) involved a migration to a new, more solid architecture to carry the weight of an integrated Extranet (with its more specialised functionality) as well as the public sites, all in one system.

In mid 2007, however, it became apparent that our little team was too small, and not skilled enough by itself, to complete the third iteration in the way we had envisaged. A major factor was the retirement of our brilliant programmer, Vitalie, who had done most of the programming for four years.

After initial dismay at this reality check, we came to see it not as a failure, but as an opportunity to embrace a new vision of how IofC’s web needs are to be met.

After some weeks of research we reached the preliminary recommendation that we should change our approach completely. Having been attempting to build a proprietary system, using our own dedicated personnel, we decided that the way forward involved engaging with an Open Source CMS project and community. Advantages of this approach include:

  1. Access to much completed programming which would save us time.
  2. Access to a worldwide network of technicians who share learning.
  3. Future sustainability more assured.
  4. An opportunity to contribute to this online community, offering to others the benefits of our own experience of the past five years.
  5. A faster way to network with other NGOs which are creating similar systems to meet their needs.
  6. ‘Open Source’ fits well with IofC’s ethos of sharing and community-building.

Drupal was recommended to us as one of the best CMS projects available. Our initial look at it confirmed that it might have most of what we needed. But there were other CMS fameworks to consider....

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.