[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: Carlos Jenkins <email@example.com>
- Date: Mon, 11 Oct 2010 11:46:33 -0600
- To: firstname.lastname@example.org
- Cc: email@example.com
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
> 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
> 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
* 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
> 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/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:
> * 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 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
> 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:
* 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>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
* 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
> 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:
> 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.
CC: Felix Delattre
To unsubscribe, e-mail to firstname.lastname@example.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.
|Re: [libreoffice-website] CMS requirements / suitability testing||Christian Lohmaier <email@example.com>|
|[libreoffice-website] CMS requirements / suitability testing||Christian Lohmaier <firstname.lastname@example.org>|
- Prev by Date: Re: [libreoffice-website] Wiki Discussion (Reboot)
- Next by Date: Re: [libreoffice-website] Website and wiki design
- Previous by thread: Re: [libreoffice-website] CMS requirements / suitability testing
- Next by thread: Re: [libreoffice-website] CMS requirements / suitability testing