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 http://www.alledia.com/blog/general-cms-issues/joomla-and-drupal-%11-which-one-is-right-for-you?/.
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 http://openconcept.ca/sites/openconcept.ca/files/OpenConcept%20-%20CUPE%20CMS_0.pdf;
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.
Internationalisation
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 http://www.developmentseed.org/blog/internationalization/comparison_chart
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.
Multisites
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.
Taxonomy
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.
Themes
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 http://drupalsites.net/.
The following sites are among those which use Drupal and can give us some
confidence that we can achieve what we need:
http://www.greenpeace.org.uk/
http://www.theonion.com/content/
Amnesty International is apparently rebuilding its sites and CMS using Drupal.