[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreoffice-website] CMS requirements / suitability testing
- Subject: Re: [libreoffice-website] CMS requirements / suitability testing
- From: Benjamin Horst <email@example.com>
- Date: Tue, 19 Oct 2010 23:59:41 -0400
- To: firstname.lastname@example.org
On Oct 16, 2010, at 7:54 PM, Andrea Pescetti wrote:
> 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.
The above represents a great and well-conceived plan. Have you made any progress in it so far? Or, are you able to work with the Drupal demo site that Keith set up in the past few days?
I'd like to give it a theme to match the current TDF website--any chance you can help create one in the next few days?
E-mail to email@example.com 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 testing||Christian Lohmaier <firstname.lastname@example.org>|
|Re: [libreoffice-website] CMS requirements / suitability testing||Andrea Pescetti <email@example.com>|
- Prev by Date: Re: [libreoffice-website] Website and wiki design
- Next by Date: Re: [libreoffice-website] [SC] Decision about CMS
- Previous by thread: Re: [libreoffice-website] CMS requirements / suitability testing
- Next by thread: [libreoffice-website] zikula first impressions: not suitable