Hi!

As an intro, the KDE wiki is running Tiki http://wiki.kde.org/

Here is rated feature list: http://doc.tikiwiki.org/Features

I will provide quick answers here based on GnomeWeb/CmsRequirements. If you need more details, just please let me know.

1. Test

Only testers going through the whole GnomeWeb/CmsRequirements/CmsTest can add their points. You can add your comments on the evaluations made. The test site is here: http://gnome.rclaporte.com/

Some notes / links here: http://gnome.rclaporte.com/TikiGnomeEval

Ranks: 0 Not supported - 1 Partially possible - 2 Possible but complex - 3 Possible and easy

Additional comments:

• Explain here anything relevant not covered by the table above.

2. CMS Platform

• State the CMS version number that is audited against the requrements Tiki 1.9.4

• Platform (i.e. what does it run on--e.g. PHP, Python, etc) PHP

• Backends (e.g. files (custom XML in CVS, etc), DB (MySQL, Postgres, etc) Uses ADOdb abstraction layer. MySQL is most popular.

• Architecture

  • "Gateway Interface" (e.g runs in mod_php / Zope app server connected to on port 8080, etc) Standard, basic PHP

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

Tiki is designed to function on basic shared hosting accounts. It's standard Apache/PHP/MySQL. We use Smarty as a template engine, which has its cacheing mechanism. Tiki also has various caches to enhance performance. However, no doubt you will have root access, so you can also install a PHP accelerator.

• List of required CMS modules to fulfill these requirements

All modules described here in basic distribution (unless I indicate otherwise). Just go to admin>feature and activate.

• 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

ok, I will comment at that time

• CPU / Mem
• Perhaps requred disk space for installation (not content)

30 Megs

3. Security

robust against attack attempts Yes. Tiki prevents users from using javascript to prevent XSS. Use of html should be restricted only to trusted editors (configurable via GUI)

some features protected by authentication Yes. All features can be protected (or not!) via a simple but powerful permission & group system. Tiki 1.9.4 offers 173, (yes 173!) different permissions you can assign to any group. And groups can be included in groups, and thereby, inherit permissions. Please see: http://doc.tikiwiki.org/SectionPermissions Permissions can be given site wide, but overriden item by item (ex.: this wiki page is restricted to group X)

option to communicate over a secure channel (SSL) Yes

upstream is active releasing security updates Yes

4. URLs

• friendly URLs, see GnomeWeb/PlatformIssues

Yes, via htaccess. Just rename included _htaccess access file to .htaccess

5. I18N

• ways to translate standard CMS strings

yes

• Use PO files here as well

Yes, via http://tikiwiki.org/tiki-index.php?page=PO%20Convertor%20for%20TikiWiki

• ways to translate content
  • How far is Tiki from using/importing/exporting PO files for publishing content in several languages?

  I need to check. There is a mail-in feature to accept wiki changes via email. Wiki pages can be watched to received changes. However, how well will the PO tools handle the wiki syntax?

  • preferably show translators what changed and what needs updating

Translators can receive an email when a page is edited.

• 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

When using wiki pages, a history of all changes is kept. However, some community discipline will be needed to keep track that version 19 of English page corresponds to version 6 of Spanish version.

• How far is Tiki from having a revision control system showing to translators what changed in the original English pages and what needs updating in the translations?

Can someone point me to a working implementation of this? This is tricky and I would like to see something to get some ideas for the UI. This would be a most welcome feature to Tiki. We need it as well for our documentation.

• preferably get language settings from browser (Accept-Language) and session (cookies)

Both built-in but optional features

• have URLs to translated pages, so they can be directly referenced

Yes, each wiki page has a different name. Please see doc.tikiwiki.org for a live example

6. Authoring

• a comfortable framework for editing content
  • can be wiki style, but does not have to

Tiki is a powerful wiki at the base, with a ton of extra features

• "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

Just edit content in private wiki pages, and then make public when they are ready.

* perhaps automatically publish on a specific date and time

Possible in articles, but not wiki pages, however wiki page content can be called in an article via a simple plugin.

• track who has rights to edit a page

yes

• 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.

If you want, but this opens the door to wiki spam. IMHO, logging in once is not the problem. It become a problem if people need to login several times because the site is being managed by several applications. With Tiki, all the features you need (and more) are available in single sign on, a consistant look & feel and cross section search engine.

• track exactly what was changed. For instance, like a diff.

It's a full-featured wiki, with nice diff features.

• can display when a page was last updated

yes, and who has worked on it.

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

All versions are kept and accessible (if you give that user view history permissions)

• copyright and licensing information can be displayed on the pages

Yes, there is a tiki copyright feature

7. Markup

• the served html should be accessible
  • with a wide range of browsers (desktop and mobile)

Yes. http://mobile.tikiwiki.org for mobile initiative (cell phones, voiceXML, etc)

• for people with disabilities

Tiki is not stellar here but we are working on it. Some themes are better than others.

• the markup should primarily capture content structure not representation
  • (i.e. "heading" versus "big bold font")

Yes, that is the goal. Tiki offers a very powerful syntax. For example, you can generate a table of content from the titles in a wiki page.

8. Navigation

• support hierarchical URLs (subdirs)

No, it's a flat structure. However, you can regroup pages via categories and/or structures.

• support hierarchical navigation (submenus)

Yes, with built-in support for phplayersmenu.

• preferably have a site map

Possible via wikigraph. However, this is not built-in and you need to install extra software on your server.

9. 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)

Tiki has built in full support for RSS (in & out). Tiki uses this library: http://www.bitfolge.de/rsscreator-en.html and thus can "create valid feeds according to RSS 0.91, 1.0 or 2.0 as well as PIE 0.1 (deprecated), OPML 1.0, Unix mbox, ATOM 0.3, or customizable HTML or Javascript format."

There are RSS feeds for all major features: calendar, wiki, articles, forums, blogs, etc

10. Theming

• shall be themeable to adopt the gnome look

Very easy. I volunteer to help. Please see http://themes.tikiwiki.org for examples

11. Expertise

There should be enough expertise in our community to:

• select (know the CMS enough to assert it meets our reqs)

That will be the tough part. It's an important decision.

• install (the whole stack, includng RDBMS)

Tiki is pretty standard php/mysql stuff, with a GUI install at tiki-install.php

• manage (keep updated and secure, without breaking it)

Stay in stable 1.9.x and you will be fine.

• fix (add missing features or critical updates not yet released by upstream)

Ahhhh, this is where it gets fun! Please contribute your fixes & patches!

12. Search

• full text search yes, built-in via all features (wiki, forums, etc) but Google site search has a nicer algorithm :-)

• perhaps keywords assigned to pages? If this is the make or break it feature for Gnome.org to choose Tiki, I commit to getting this feature added in the main Tiki distribution

• something else?

13. 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?

mysqldump + copy all files restore the mysqldump.sql + restore the files