Re: [libreoffice-website] CMS requirements / suitability testing

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.

Best regards,
  Andrea Pescetti.

--
E-mail to website+help@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/website/
All messages you send to this list will be publicly archived and cannot be deleted