Christian Lohmaier wrote:
as the question "what cms to choose" now comes up more often, I think
it's best to just setup some demo-sites to compare them.
(Oops, my message from last week didn't make it to the list, my fault... resending now, edited to
reflect current state of the thread; sorry, it will get rather long)
As a seasoned OpenOffice.org volunteer (Italian N-L Project Lead for the
last 5 years; active in QA and l10n projects) and member, as my daily job, of an experienced
Drupal Development team (focusing on medium-large
international projects and regularly presenting at Drupal Conferences
from 2007 onwards), I've often made the exercise, after undergoing the necessary evil that CEE
is, to think how the OpenOffice.org infrastructure could be rewritten in Drupal.
The setup of a demo site would/will take some days, but I can already
share some facts with you. It goes without saying that all of these are
true and tested in my professional experience. [I removed from the answers below those points
that have already been addressed].
* Create static pages
For a very large site you want to put your site under a dedicated
caching engine like Varnish (which is what OOo Templates and Extensions
currently do, we had some nice discussions in Budapest at Thorsten
Bosbach presentation, I can't check if the video is available right
now); Boost will "staticize" the site pages in a way similar to the one
you describe (and rely on .htaccess + PHP for answering not-cached
requests), but I would not use it alone; due to a better handling of
anonymous users, Drupal 7 (due "soon", but in a "release when it's
ready" model) would make a difference here. Anyway, techniques aside it
will be important to have numbers here, and I'll be able to answer your
request with numbers if/when I have a demo site ready.
* User-Firendly URLs
Drupal can be easily and reliably be setup for this kind of URLs, with
proper transliteration of non-ASCII characters and categorization (like
automatically put events under example.org/event/xyz or define the alias on a page-by-page
basis). The rest has already been addressed here.
* Support for Translations
Key pages should be available in multiple languages
There is translation support and when a new page is created the editor
can decide whether it is to be translated in other languages or not.
Language detection on the browser can be used to serve content. Support
for translation management is available in the backend. But do we really want translations? The
current discussions about the wiki concluded that we will still need a namespace for individual
projects, since content will differ, as it is in the OOo infrastructure where each project
maintains a separate site and not individual pages translated from English.
* Support for subsites
You can have subdomains in a similar fashion to the OpenOffice.org
infrastructure. A so-called "multisite install" allows to share some
settings across sites (already discussed). Since I happened to work quite often with large,
distributed organizations, I can guarantee that it is easy to share accounts across all the
sites, with nice single-sign-on solutions, and automatically keep them in sync. Since this is not
very standard in Drupal, I'll provide a link:
http://developmentseed.org/blog/2010/mar/02/simple-sign-openid
(this also turns Drupal into a kind of OpenID provider, very useful to enable single
authentication from other sites too, like a Templates or Extensions repository).
Moreover, Drupal has a powerful built-in support for cross-sites aggregation; besides providing
good and very customizable RSS feeds, it can automatically retrieve and display content from
subsites, making it possible to build an "aggregator site" that displays, possibly in an
interactive map, activities from all the local projects (OK, here we have the usual
language/country issue, but still this is something I definitely miss in the OOo sites network).
* sufficiently sophisticated user-rights system
[Superseded by messages arrived in meantime]
* user friendly editor
Already discussed. I'll only add that I feel the OOo community members could be perfectly at ease
with the Markdown filter. I tend to avoid WYSIWYG in favor of the "What you see is what you mean"
approach of Markdown recently, and this guarantees cleaner code with no significant impact for
normal editors with the level of skills I've normally seen in OOo volunteers.
http://daringfireball.net/projects/markdown/syntax
* I cannot see a way to have a hierarchy (only very, very limited),
Do you mean a menu hierarchy or a page hierarchy? You can have both, anyway, and out of the box.
To see the menu hierarchy in a drop-down fashion you'll have to choose a graphical theme
supporting it. To have a page hierarchy you merely use the default "book" module which provides
you with a 9-level page hierarchy.
Those are the basic requirements that come to my mind
Well, Drupal has another killer feature if you consider the structure of the OOo community: with
the Code-Driven Development techniques, you can collaborate remotely and work together on a site
at the same time. For most CMSs this is impossible because settings (like, how many items should
be displayed in the "latest news" block in the homepage; or what additional modules are
installed) are stored in the database, and this forbids to have separate development sandboxes
and merging them cleanly. With Code-Driven Development, you export all your settings to PHP code
automatically, merging is clean and safe and versioning is effective again: you can browse the
SVN/GIT/mercurial history and see what settings were changed and when. This way you also solve
the major drawback in database-based CMSs, i.e., tracking changes that are normally buried in
database. I guess this is the reason why the OOo Templates/Extensions site is managed by a single
developer: cooperation would be very hard on that old (Drupal 5) infrastructure.
I'd be happy if someone else could do this for drupal or whatever
other CMS you think should be in the closer choice.
Got it! Yes, I understand there are only words above, and you would like to see a concrete,
dedicated, demo site. Based on my experience in the OOo community, I would totally go for a
code-driven approach because this is the crucial advantage Drupal 6 offers on other
database-based CMSs; I haven't seen Keith's initial setup, but if it follows this approach I'll
happily have a look. Otherwise... OK, tell me if there is still interest in a Drupal demo and
willingness for a fair assessment and we'll see.