Comparison Table

Feature / WikiEngine

MoinMoin

Tiki Wiki CMS Groupware

TWiki

PHPWiki

MediaWiki

Confluence

Database

works without

MySQL

works without

any dba/ ADODB/ PearDB or files

MySQL, PostgreSQL or SQLite

mySQL, PostgreSQL, Oracle

Programming Language

python

php

perl

php

php

Java

Categorization

using backlinks

nested categories and/or structures and/or tags

by webs, tags, parents, forms

using backlinks

real categories, tree plugin

spaces, pages, links

Groups

yes (users, pages)

yes, also nested groups possible

yes, also nested groups possible

yes

limited

yes

Versioning

yes

yes

yes. RCS default / Subversion experimental

yes

yes

yes

Latex Formulas

add on

plugin (currently disabled -- security issues)

plugin

plugin

yes (installation separate)

plugin

Tables

yes

yes

default plugin

yes

yes

yes

Inlined HTML

add on

yes

yes

subset

yes, limited

plugin

Email Notification

yes

yes

yes

yes

yes

yes

Comments

add on

yes

plugin

plugin

on discussion page

yes

Feature / WikiEngine

MoinMoin

Tiki Wiki CMS Groupware

TWiki

PHPWiki

MediaWiki

Confluence

Permissions

ACLs

elaborate permissions assignable to groups

yes, assignable to groups

ACLs

limited

extensive enterprise-level

Performance1

fast

fast

a little slower

fast

a little slower (pretty slow)

Extensibility

plugins, themes

plugins, modules, web services

plugins, skins, add-ons

plugins

plugins

plugins, XML-RPC, SOAP

Unicode Support

complete

yes

partial

unknown

yes

yes

Right to left support

yes

yes

no

unknown

yes

unknown

Search

multiple words, regular expresions, boolean

yes

multiple words, perl regular expressions, specific scope, stopwords

title, full text, fuzzy

yes

yes

Spam protection

yes (Antispam, ip blocking)

yes

yes (BlackListPlugin)

unknown

ip blocking, quick mass reverts

CAPTCHA

Usability

easy

easy

easy

easy

easy

easy

WYSIWYG

yes

With CKEditor

yes

?

?

yes

Installation

medium

easy

Unix: Easy, Windows: Hard, Virtual Machine: Easy

unknown

very easy

easy

Feature / WikiEngine

MoinMoin

Tiki Wiki CMS Groupware

TWiki

PHPWiki

MediaWiki

Confluence

Server options

standalone, Twisted, fast cgi, modpy, cgi

Apache with PHP, IIS, MacOS X, Standaline,For Images: GD Library 1.5 (or higher) or ImageMagick

cgi, mod_perl, speedycgi

unknown

PHP backed by SQL on Apache or IIS

included (Apache Tomcat 5.5), or run with the appserver/webserver of your choice

Configuration

easy, powerful (multiconfig for wiki farms)

Straightforward

config file and web (TWikiPreferences)

unknown

easy (web based)

administrative interface

Maintenance

sweet (separated system and wiki pages)

easy (Install-Script to update DB to other Version and all features are built-in)

Upgrades are clumsy and time-consuming, due to mingling of application code with data and local customizations

unknown

unknown

frequent upgrades (approx. 10 per year)

Clobber Protection

(Optionally unconditional) timed Lock, 3-way merge

Popup-Message before Editing

Timed warning, 3-way merge

unknown

Merge

unknown

RSS Feed

Yes

Yes

Yes

Yes

Yes (through special pages)

Yes

Windows(NTLM) Authentication

?

Only aganist other Servers (ADS, LDAP, PAM, CAS)

Yes + LDAP in general (plug-ins)

?

LDAP plugin supports Windows Domains and general LDAP

LDAP/ADS is supported. Wih Crowd (optional) it's a full Single-Sign-On

License

GPL

LGPL

GPL

GPL

GPL

commercial, free for open source & non-profits

Feature / WikiEngine

MoinMoin

Tiki Wiki CMS Groupware

TWiki

PHPWiki

MediaWiki

Confluence

Comments

General

Personal remark: I always wanted to have such a WikiEngineComparison page and already had a deeper look at WikiEngines but I am very unhappy with all of them. Such feature lists do not help much. They don't describe the wiki engines properly and they especially doesn't answer the important question: "Which is the engine that meets my needs best?" And even more important: "Which engines should I avoid?" I'll try to describe MoinMoin but as already said this is not easy... -- FlorianFesti 2004-03-11 15:59:30

The problem with these comparisons, is you have to learn and work with a wiki for some time to evaluate its qualities and weakness. Nobody can have experience with all wiki engines out there... -- NirSoffer 2004-03-12 02:11:45

Another wiki engine comparison is available at http://www.wikimatrix.org -- you can choose which wiki you want to compare in a side-by-side feature table. Their Choice Wizard and/or search can be very helpful if you aren't sure of what names to choose.

Features

Group Viybel 01/12/2004 : are "Groups" refering to pages' groups or users' groups?

Ease of installation A row in the table above should be added for "ease of installation". I suppose experts can infer that from the other listed items, but a rough idea of how quickly one can set these things up would be helpful.

Ease of Hacking I've not played with any other wikis extensively, but I think "ease of hacking" should be a consideration. I've found MoinMoin to be incredibly easy to extend. Themes, macros, and actions all work together to allow you to do anything you want with the wiki. The simplicity of moin translates into simplicity of change. For the wiki I've been working on we've changed nearly everything. -- PhilipNeustrom

WikkaWiki is extremely "hackable," with extensive development documentation available. --Brian Koontz

WYSWYG editing Could you add a feature of WYSIWYG editing (using htmlArea)? -Benjamin Hill

Looks like twiki has one - http://twiki.org/cgi-bin/view/Plugins/KupuEditorAddOn - Benjamin Hill

No kupu http://kupu.oscom.org/ is actually a html editor based on epoz http://epoz.sourceforge.net/ which was designed as a wysiwyg editor for zope based websites. The actual addon is rather poor at best, it can only edit pages that already exist, it works by converting the html outputted by kupu into twiki markup. Essentially it is a hideous hack. Although the twiki maintainers are interested in integrating some kind of wysiwyg editor.

Ed.wiki has an integrated WYSIWYG-Editor. But you can't make it with a plugin, you have to rewrite all the wiki logic http://www.wb-giessen.de/edwiki (its german, prepared for i18n, translation needed)

As of MoinMoin version 1.5, there is has a great WYSIWYG GUI editor as described in MoinMoinFeatures

Clobber Protection Added Clobber Protection - Benjamin Hill

Email notification What does email notification mean? Automated email notice of changes in certain page? If so, Mediawiki does not have it yet (as of early 2005). -- Tomos

MoinMoin

Main focuses of MoinMoin are:

To make it short: it is very easy to integrate other formats or applications into MoinMoin and "integrate" means: making them available within wiki pages and not just putting a link on them.

See MoinMoinFeatures for details.

Main flaws of MoinMoin:

Other flaws related to the developers:

MediaWiki

MediaWiki - the version used at wikipedia is NOT easy. Try to add some content and you will see how hard and annoying it is. Too much options and syntax, lot of work to download a file and in-line it in your text. MoinMoin is much better - less clicks and simpler syntax. I wonder if its because of my experience with moin syntax? -- NirSoffer 2004-03-12 01:49:32

MediaWiki is certainly pretty slow despite lots of kit to support it. -- AndrewCates

I think Wikipedia is slow many times, but others are very fast - an example: http://www.tsunamihelp.info/wiki/index.php/Main_Page -- Tomos

Wikipedia has thousands upon thousands of users... It is not possible to make any conclusions about performance without looking at server capacity and load. One thing we can say is that Wikipedia has proven it can handle huge numbers of pages and accesses. -- Erik

MediaWiki and MoinMoin have different targets. See the related comments from Brion (a media wiki developer) in MediaWiki.

For a more specific comparison, see MoinMoinVsMediaWiki.

WackoWiki

http://wackowiki.org/doc/

Is also a nice wiki based on php and mysql. -- Dick Stins

Nice Features, but I don't like the markup it uses.

Structured Data and Dynamic Pages

For some applications it´s very important to store and receive structured data. Here TWiki has an amazing functionality: The data can be stored using forms, and it can be retrieved in dynamic tables with sorting and filtering. see FeatureRequests/IntelligentDynamicTables. -- TobiasPolzin 2006-01-17 20:52:40

File Storage

Which is more effecient, storing wiki pages in a flat file, like JSPWiki does? or in a mysql table, like PhpWiki or XWiki do? I am concerned about the efficiently of handling big number of pages and attachments as well. Is a mysql table good enough to keep up with the growth of a wiki?

What do people think of that? -- Marion Hanz

Start by defining what you think "big" is. -- JürgenHermann 2005-11-09 18:12:12

I simply don't have a long experience with wikis to be able to state how is the efficiency by using a database or a flat file, that's why I'm posting this point here. Regarding installation and set-up though, of course a flat file storage is better, then it does not require more than just setting a page or attachment directory in some config file. A database-envolved set-up might be cumbersome for an unexperienced user, but this is not my issue. I am more interested in the performance and maintenance of the data in both cases in a growing wiki. - Marion

I just noticed that you are refering to "big number of pages", sorry, did not think, you meant that. Well, the wiki of choice will be set at a university department for the purpose of research. Employees as well as students will have an access to it. It will be an active wiki, which means, there will be a lot of contributions happening which in the end will make the wiki having to deal with a "big" number of pages and attachments, the size of both including versions are of course meant with big number. - Marion

Is big 1000, 10000 or 100000 pages?

Do you actually have something to say for this topic, or you are just trying to get an attention?? - Marion

I tried to answer your question, after getting a precise one. I stop now.

What should that mean? are you mad? Thank you anyway for having made an effort, although no one saw something from you. Things do not stop when you stop though...

As JürgenHermann asks I am interested in the answer too about how much pages we are speaking here? I don't know why it is so difficult to tell I like to use a wiki server which is able to handle about 100000 different pages. Whatever you tell us it is very easy for one of us having already a wiki to create such an amount of pages if we don't have them already. Afterwards we could probably tell something about maintanace, performance. -- ReimarBauer 2005-11-11 10:04:54

Ok, since it is for research purposes, I'd like the wiki to be able to handle a number of 200000 different pages. Which kind of wiki is better for maintanace and performance? Marion

I have organized our wiki by a farm configuration. So each group has it's own wiki instance with for example a separated search engine, separated title index, separated acls. Do you ask here for a similiar installation or do you want a TitleIndex over 200000 pages? I like to tell some more about the background I was asking this. If you set up one wiki for all institutes then you need a very good acl ruleset to destinguish who is able to give someone rights to edit a page. Probably the institutes people do have some pages which should not be seen in public and they have some pages which a subset of their members should edit and all others could only read. And some other pages could be edited by all members. By using one wiki for several institutes you have to add a prefix to a lot of pages. e.g. institute_FrontPage, institute_*templates. It could be difficult to find something useful by search. I believe it is more difficult to use one wiki instead of a farm. -- ReimarBauer 2005-11-11 22:25:08

I don't have time to update the TWiki column unfortunately, but TWiki 4.0 improves on quite a few areas listed here, including clobber protection, performance options (now works better with mod_perl, SpeedyCGI, etc), skins, security, code modularity, internationalisation (translated into several languages), etc. http://www.wikimatrix.org/ is more up to date, or see http://twiki.org/ for latest features. -- RichardDonkin

I currently run a wiki at my company (internally) and it has around 24,000 pages. It's running on a quad core RHEL 5 box with 3 GBs and is served with Apache running mod_fastcgi (4 threads). For text searches, we are using lupy (since non-indexed searches take forever, oh and for best performance, we are reindexing the wiki every night). We are noticing big slowdowns on our server due to the text search being dog-slow (even with lupy, if someone did a 4 word search it may take anywhere from 30 sec to 600+ seconds, depending on the terms being searched). Does anyone know of anyway to speed up moinmoin? Should I jump ship to media wiki since with a database backend, I could easily replicate and load balance to improve performance? - counterpoke 8/9/2007

See also

  1. Just an impression of my test-installation. (1)

MoinMoin: WikiEngineComparison (last edited 2017-04-17 01:10:35 by p50844ADA)