CMS selection

This goal is completed. The work follows at GnomeWeb/CmsSetup

And the winner is... Plone! After a lot of discussion and reviewing, this seems to be the most appropriate CMS for the revamped www.gnome.org here and now. The second option in this tight final has been Midgard, the CMS powered with GNOME libraries. The reasons for choosing Plone rely more on people than code, since both tools could reach all the requirements with hacking and good will.

Three other candidates were dismissed previously and we needed very good arguments to do so. The localization recommendations made by the GNOME i18n team were crucial in the selection. See why not TikiWiki and why not eZ Publish or Drupal. Something learned in detail during this process is that apparently simple tools can match your requirements if you have the knowledge and the resources to do so. At the end this is a reason why we love free software so much.

Thanks to all the people that invested time willing to find the most appropriate CMS for www.gnome.org. Plone/Python hackers and anybody interested in contributing to the wgo revamp can join us at gnome-web-list. RamonNavarro is leading the Plone implementation.

All of the ab ove belongs to the CMS selection process

CMS requirements for www.gnome.org

This is a list of categorized requirements for the CMS system that will serve www.gnome.org. If you recommend a CMS check this list against its features.

• GnomeWeb/CmsRequirements/DrupalEval - Drupal evaluation - Test site: http://gnomedotorg.ourproject.org/drupal/

• GnomeWeb/CmsRequirements/MidgardEval - Midgard CMS evaluation - Test site: http://devel-xen-stable.nemein.net/

• GnomeWeb/CmsRequirements/eZpublishEval - eZ publish CMS evaluation - Test site: http://wgo.mgdm.net/

• GnomeWeb/CmsRequirements/PloneEval - Plone evaluation - Test site: http://demo.gnome-cn.org

• GnomeWeb/CmsRequirements/TikiEval - Tiki Wiki/CMS/Groupware evaluation - Test site: http://gnome.rclaporte.com/

More at GnomeWeb/CmsRequirements/CmsTest

See also GnomeWeb/PlatformIssues

CMS Platform

Please provide the following info about the CMS candidate

• State the CMS version number that is audited against the requrements
• Platform (i.e. what does it run on--e.g. PHP, Python, etc)
• Backends (e.g. files (custom XML in CVS, etc), DB (MySQL, Postgres, etc)
• Architecture
  • "Gateway Interface" (e.g runs in mod_php / Zope app server connected to on port 8080, etc)
  • Short description of software architecture or link to such document (major components (such as auth, editing, caching, etc), important data flows, bottle necks (esp. database hammering))
• List of required CMS modules to fulfill these requirements
  • State the version number that is audited against the requrements
  • Can list alternate CMS modules if several solutions exist
  • State whether it is an "external module" (not in base CMS distribution)
• Resource usage
  • External runtime dependencies (mod_php / database / 3rd party libs)
    • State minimum required version number if appropriate
  • Anticipated system requrements for current known work load (best effort guess is fine)

    • http://www.gnome.org/stats/usage_200606.html

    • For now this is just informative, we'll try to come up with better numbers based on expected future work load expected after the revamp
    • CPU / Mem
    • Perhaps requred disk space for installation (not content)

Security

• robust against attack attempts
• some features protected by authentication
• option to communicate over a secure channel (SSL)
• upstream is active releasing security updates

URLs

• friendly URLs, see GnomeWeb/PlatformIssues

I18N

• ways to translate standard CMS strings
  • Use PO files here as well
• ways to translate content
  • preferably show translators what changed and what needs updating

    • This is a must for me. Translation is impossible without it, and out-of-date translations are worse than no translations. For others, translation via .po files might be a must. MurrayCumming

    • PO files are a MUST for The Gnome TranslationProject—we don't want to reeducate all the translators with new policies, and take away their tools (translation memories, fuzzy matching, status pages...) DaniloSegan

      • Thanks for clarification. Since PO files and revision control are a key factor, I'm asking to the developers of the evaluated CMS how far are they from offering these features. See the evaluation pages for details and URLs.
• preferably get language settings from browser (Accept-Language) and session (cookies)
• have URLs to translated pages, so they can be directly referenced

Authoring

• a comfortable framework for editing content
  • can be wiki style, but does not have to
• "draft" content, which is already managed in the system, but not yet published
  • translators can do their job before content appears to the public
  • pre-edit text to be published at a specific date and time
    • perhaps automatically publish on a specific date and time
• track who has rights to edit a page
• track who did edit a page

  • I think we should default to anyone being able to edit a page. Logging in is already an obstacle. MurrayCumming.

• track exactly what was changed. For instance, like a diff.
• can display when a page was last updated

• perhaps change management, so older version of a page can be recalled

• copyright and licensing information can be displayed on the pages
• It must be easy and fast to publish content

  • Often, we have transient projects or announcements ("new gnome journal is out", "WSOP contest is in place", "register for GUADEC now") that need to be put in the web site very quickly, and by people who are not part of the web team. The problem becomes finding someone from the web time with enough time to take the announcement and put it up. ((FedericoMenaQuintero).

Markup

• the served html should be accessible
  • with a wide range of browsers (desktop and mobile)
  • for people with disabilities
• the markup should primarily capture content structure not representation
  • (i.e. "heading" versus "big bold font")

Navigation

• support hierarchical URLs (subdirs)
• support hierarchical navigation (submenus)
• preferably have a site map

Feeds

• shall provide feeds (RSS, Atom, etc)
  • news (for visitors)
  • site updates (for content authors)
• peferably shall integrate external feeds (e.g. from gnomefiles.org)

Theming

• shall be themeable to adopt the gnome look

Expertise

There should be enough expertise in our community to:

• select (know the CMS enough to assert it meets our reqs)
• install (the whole stack, includng RDBMS)
• manage (keep updated and secure, without breaking it)
• fix (add missing features or critical updates not yet released by upstream)
• It has to be really easy to pick up the maintainership of the web site in general.

  Our web maintainers become overworked and eventually disappear. The web page becomes stale because then there is no one who understands the previous CMS (FedericoMenaQuintero).

Search

• full text search
• perhaps keywords assigned to pages?
• something else?

Backup

• it should be easy to make backups
• it should be easy to restore backups
• perhaps a replicate server in case the main one goes down?
  • perhaps clustering?