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

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.

Follow-Ups:
Re: [libreoffice-website] CMS requirements / suitability testingChristian Lohmaier <lohmaier+ooofuture@googlemail.com>
References:
[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.