Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

Quick of the top of my head thoughts, written in line as I read.


[libreoffice-website] CMS requirements / suitability testing

Christian Lohmaier
Wed, 06 Oct 2010 23:39:10 -0700

Major points any CMS must fulfill:

* Create static pages
In the past, on the 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.

- Should the CMS have the ability to interface with a cvs system, used
to maintain these static pages - even if the CMS offers a way to create
static pages it is hard to conceive of not having people contribute
pages created outside of it. 

- load can overwhelm poorly integrated sites, even if some of the pages
are static - of course this can me mitigated even further by looking at
using static pages where it is planned to receive the vast majority of
entry into and exit from the site, either from that single static page
or through a well thought out path that leads to same. 

- If however you have a nice static entry location, but then to do much
of anything the users will be pushed into displaying content from, or
sending input to, the CMS system then the benefit is reduced.

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

- Yeah OK - details for any good implementor to be given as part of the
task, I don't agree with all the arguments there but I understand them
and believe just about any system can be set for that - is it worth the
added load on the systems, and implementation time, in the end...many
feel so and I suppose then it is.

* 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, without the editor needing to update all
translations with a new link)

- define managing

* 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)

- yes ( I think this is a red herring as no package is being considered
were this is a concern )

* 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. Specifically, it should 
support a review/approval workflow.

- OK

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

- ambiguous - either is an import topic (factor in choice) or it is, not
so much of a concern. (need to chose) [I would go with the "not so
important", as most offer a workable baseline of funtions]

Those are the basic requirements

Areas it does not need to provide:

* an own wiki
Specialized wiki-software is always superior

- Should the two work together, could you embed the output of one into
the other, can you use the CMS to create wiki pages?

* own Forum
See wiki

- see above - pretty much all decent BBS now are such that they can be
embedded. It is still a separate system and can be used such of course.

* random other addition (blog, whatever)
see wiki / we have dedicated planet

- and it would be great to have the ability to build my own personal
"Planet" - so if I work on, or an tracking, issues, activities or user
opinions expressed in social media service sites, I could construct my
page to display this aggregated view - the issues, and activities and
even projects that I might be interested in today may be different from
those 3 months from now - so I would prefer that this not be a static
choice of data stream sources. 

- I am of course expanding the definition of planet there, just used for
artistic flairt :>)



Having now the specs., we have narrowed down the choice to Silverstripe 
and Drupal.

Here are the demo sites:

Silverstripes: -- advocated by Christian 

Dupal: -- advocated by Keith 

 From here we should first examine if both of these fill the basic 
requirements as laid out in the specs up above.


E-mail to for instructions on how to unsubscribe
List archives are available at
All messages you send to this list will be publicly archived and cannot be deleted


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.