WikiEngineComparison"

Comparison Table

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

• I get asked this a lot because of my personal wiki and the PersonalTelco wiki. I finally published a copy of my WikiReview if anyone is interested. It's not intended to be exhaustive in any sense but to answer the questions I get asked repeatedly (ie. "what wiki do you use" and "what wiki should i use for ..."). BTW, I think you're missing out by not comparing MoinMoin to PmWiki and Oddmuse which are two of the best up and coming wiki's available. -- AdamShand

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

• See PythonWikiEngines which already does this for python-based wiki engines.

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.

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

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

• Most WYSIWYG editors output HTML. If you can find one which does not generate HTML but wiki markup, we would look forward to integrate it.

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)

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:

• Wiki and only wiki: MoinMoin has a large number of features but they are all related to wiki. There are no discussion section, bulletin boards or other stuff like this. We see this as a strength.

• Lots of MoinMoin features aim at intranet use. Either because they may be problematic in public use (Attachments, ...) (btw. we use most of them in our public wiki anyway) or because they don't scale to very large wikis (embedding search results into pages). Nevertheless there are some MoinMoin wikis on the BiggestWiki list. But if you want to start a wiki encyclopedia you may want to use MediaWiki.

• Extensibility: As you can see above every (well known) wiki supports plugins. MoinMoin supports the following plugin types:

  • macro: embed a function result into wiki page (see HelpOnMacros, MacroMarket)

  • action: do anything (see HelpOnActions, ActionMarket)

  • parser: support other formats as a page in the wiki (see ParserMarket)

  • xmlrpc: do remote procedure calls using xml (that is very easy in python)

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.

• Ease of use: MoinMoin is intended as a tool for collaboration. It does not primary focus on good looking documents but on glueing communities together. (Although MoinMoin pages don't look that bad)

See MoinMoinFeatures for details.

Main flaws of MoinMoin:

• It is not built to scale up to very large wikis (>>10.000 pages).

Other flaws related to the developers:

• Only few unit tests
• Design problems - little separation of logic and view, unclear responsibilities

Media wiki

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 guess scalability has its cost... -- FlorianFesti 2004-10-01 10:00:58

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

• Yeah, scalabity is not null. They do a hard job increasing it to a level where it needs to be in order to support those billions of page impressions. (loadbalancers, DB replication, turkcache, static HTML caches, etc. pp.). One might ask if it might be desirable to have scalability built-in.

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

• This is true. The way attachments are handled in MediaWiki make it, in my opinion, untenable for an intranet. MediaWiki has one flat space for attachments, so that every one has to have a different name. File uploads are also handled using a "special" page that's separate from the page you want to link the attachment, making link to a file even more difficult. I think this is just a reflection of the fact that MediaWiki is designed for the wikimedia projects, where you have people working on a single collective project. Everything is encouraged to have "top-level" visibility. In a company, where working groups are often working on separate projects, features like subpages and page attachments make sense. You don't want John to have to worry that Fred down the hall already uploaded memo.doc. --GregWhittier

For a more specific comparison, see MoinMoinVsMediaWiki.

Wacko wiki

http://wackowiki.com/WackoDocumentation

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

• Feel free to add it to the table above.

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

See also

• http://www.wikimatrix.org/ - Wiki Feature Comparison