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

Hi everybody, thanks for good work.

I'be also setup a lot of sites on Drupal, the drush utility is the best out
there, from my point of view. I'll try to answer some questions on this
e-mail. First of all, sometimes we prefer to call Drupal a framework, rather
a CMS, or a Framework-CMS. Out of the box Drupal doesn't do much, but once
you start configuring, Views, CCK, drush, everything get amazing. It's so
flexible that putting a demo site "configured" will be so specific, but
sure, maybe it would show more of their capabilities. Anyway, that's a
good suggestion to the Drupal Community.

2010/10/7 Christian Lohmaier
<lohmaier+ooofuture@googlemail.com<lohmaier%2Booofuture@googlemail.com>
>

> Hi *,
>
> 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.
>
> I'm currently evaluating silverstripe, and so far it seems to be good
> enogh:
>
> Major points any CMS must fulfill:
>
> * Create static pages
> In the past, on the OpenOffice.org website with SourceCast (now named
> CEE) we often had the problem of the site going down because of the
> amount of requests. A pure php driven site, even with php-accelerators
> very likely will put too much load on the server.

I've never put a site with the expected traffic of LibO new site,
if aggressive caching + memcached or something + good apache, php and
MySQL optimizations it's not, maybe you need will need boost, check this two
links:

http://www.bestofdrupal.com/boost-static-page-caching-drupal.html
http://drupal.org/project/boost

* User-Firendly URLs
> People want to be able to guess what a link is about. Pointing someone
> to http:://example.com/<randomnumber> is bad, better point to
> http://example.com/user-faq
> Also important for search-engines and the like

This is called URL-rewrite by Drupal. It's in the core. If not enabled URLs
look like domain.com/index.php?q=node/210. If enabled but not set the URLs
look like domain.com/node/210. If you set a URL manually (functionality in
the core/optional/path) or if you use Pathauto module, you URLs can llok
whatever you like, for example domain.org/article/datearticle, even you can
use Taxonomy (something like categorization).

Those will be absolutely necessary:

http://drupal.org/project/pathauto
<http://drupal.org/project/pathauto>http://drupal.org/project/globalredirect
 <http://drupal.org/project/globalredirect>
http://drupal.org/project/transliteration (because of the i10n)


> * Support for Translations
> Key pages should be available in multiple languages, the CMS should
> support managing those (without having the editor keep the list of
> translations in sync, wihout the editor needing to update all
> translations with a new link)

Not sure what complex translations needs LibO have, but almost sure Drupal
can cover it, check:
http://drupal.org/project/i18n


> * Support for subsites
> As LO is a huge project, with lots of different areas where work is
> being done, the CMS should support multiple subsites. (like for
> example on OOo the various native-lang projects, the marketing,
> distribution, etc. projects, that have different focus and needs)

No problem, the Drupal installation has sites/ folder on his root. The main
site is located (if you want to) in sites/default, any
other additional subsites (or totally different sites) are located on
sites/sitename. This can be set without problem to subdomains and
virtualhost on apache. You can share modules between all sites and have
site-specific modules. This is done because you have:

sites/all/modules (shared modules)
sites/all/themes (shared themes)

sites/default/modules
sites/default/themes

sites/subsite1/modules
sites/subsite2/themes

....etc

Sites can share database or use another one. Authentication can be done
easily, OpenID is built-in the core (core/optional/OpenID) or you can use
things like LDAP: http://drupal.org/project/ldap_integration. User database
table can be share between subsites but this is an advanced thing.

* sufficiently sophisticated user-rights system
> Not every user should have the possibility to change every aspect on the
> site.
> Some parts are reserved to be edited by admins, some areas are free to
> be messed-around by community members.

No problem I think, Drupal permission system is one of the most advanced and
permit more granularity I've seen. You can create roles and give a lot of
permissions to that role, even, with CCK, you can specify who can View or
Edit a single field.


> Specifically, it should support a review/approval workflow.

You can setup a content type that is by default no published, and user role
X can not change that, then, role X can publish it. This could be a
rudimentary setup. If not enough, you can try things like this one:
http://drupal.org/project/workflow. Check out this video about that:
http://www.lullabot.com/videos/drupal-actions-and-workflow-video

* user friendly editor
> Probably not so much of a concern, as many will use the same tinyMCE,
> but nevertheless an important topic

http://drupal.org/project/wysiwyg

<http://drupal.org/project/wysiwyg>You can use TinyMCE, I don't like it, I
prefer CKEditor http://ckeditor.com/ .All this are supported:

Editors: CKEditor, FCKeditor, jWysiwyg, markItUp, NicEdit, openWYSIWYG,
TinyMCE, Whizzywig, WYMeditor, YUI editor.

Those are the basic requirements that come to my mind, now to stuff it
> doesn't need to provide:
>
> * an own wiki
> Specialized wiki-software is always superior

Sure, I agree. You can do interesting thing with MediaWiki and Drupal
integration:
http://www.mediawiki.org/wiki/Extension:DrupalIntegration
http://www.mediawiki.org/wiki/Extension:AuthDrupal

* own Forum
> See wiki
>
> * random other addition (blog, whatever)
> see wiki / we have dedicated planet
>
> The only drawback of silverstripe I found sofar is user account
> creation/validation.
> By default the email is not verified by sending a probe, thus a user
> can create an account with an email-address that he/she doesn't own.
> Only burden is a captcha. This puts a little burden on the
> administrators to double check

Drupal can send e-mail for validation if you want to and configured that
way. Didn't understand about the burden, sorry my English, but you can use
re-captcha or captcha on Drupal:

http://drupal.org/project/recaptcha
http://drupal.org/project/captcha


> I can provide access to a staging installation soon, to check things out.
> I'd be happy if someone else could do this for drupal or whatever
> other CMS you think should be in the closer choice.
> The static sites requirements is considered a hard requirement, no
> "but it is fast without" arguments please. To quickly get an idea how
> your site performs, use the apache benchmark utility, request a site
> 1000 times with concurrency of 5. That can be used as a measure to
> compare cached/static vs dynamic performance.

Cheers

CC: Felix Delattre

-- 
Carlos Jenkins
http://www.cjenkins.net/
http://csl-tec.softwarelibrecr.org/

-- 
To unsubscribe, e-mail to website+help@libreoffice.org
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.