[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

[libreoffice-website] CMS requirements / suitability testingChristian Lohmaier <lohmaier+ooofuture@googlemail.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.