[Home]WikiEngine

MeatballWiki | RecentChanges | Random Page | Indices | Categories

1. WikiEngine or WikiClone?
2. What WikiEngine should I use?
3. Q & A

More likely a "Wiki script". Basically, various implementations of a wiki. MeatballWiki maintains a short (or perhaps long) [listing] of ones salient to our discussions.

1. WikiEngine or WikiClone?

The historical and some might claim canonical term is actually "WikiClone", a term originally coined to describe sites built with software imitating the WikiWiki idea before WikiEngines were common. FridemarPache has since rebuilt the entire ontology at WikiWiki to be more consistent and clear; i.e. to differentiate the software at the back end of a wiki from each separate instantiation of a wiki - whereas before it could have been said that, for example, "MeatballWiki is a WikiClone", it would now be said that (obviously) "MeatballWiki is a wiki".

'Reason for the use of WikiEngine: The modern use of the term "Clone" in biology is: "An exact copy made of biological material such as a DNA segment (a gene or other region), a whole cell, or a complete organism." [1]. Modern wiki scripts are not simply "cloned" code (more or less modified) of WardCunningham's original WikiWiki engine, but code, based on the Wiki:WikiPrinciples.

We support that naming system here, although people often shortcut to just saying "a wiki" rather than "a WikiEngine". "A WikiForum" is also available as a synonym to "a wiki", although it is infrequently used. For an exhaustive, or perhaps exhausting, summary of the meanings of "wiki", see WhatIsaWiki and Wiki:WikiEngine.


2. What WikiEngine should I use?

This question is very important to me just now, but there is another facet I am also forced to consider. Specifically, should I "rent" wiki services, as opposed to "buying" them. (I added a toc to minimize my 'disturbance in this force' and will refactor to a separate page if need be) -- HansWobbe
Removed to [HwoRentOrBuy]

There are many many wiki engines (too many? see CommunityWiki:TooManyWikiEngines) out there. If you want the original, go to

http://c2.com/cgi/wikibase

You can also buy the book TheWikiWay to get whatever the latest version of QuickiWiki? is. But if you want something more mature that's another story.

Some good wiki software. (There are many more. See Wiki:WikiWikiClones and Wiki:WikiEngines.)

PhpWiki (PHP)
Probably the most faithful to the original wiki of this list.

PmWiki (PHP)
One of the easiest to setup, works on many hosts, very active development community

TwikiClone (Perl)
Probably the most divergent, but powerful.

MoinMoin (Python)
Very, very, very popular. Possibly the most popular. Being implemented in Python this is easy to extend - even if you never heard of Python before.

PikiePikie (Python)
Functions very nicely as a "WikiLog."

ZwikiClone (Zope)
If you like Zope.

WikkiTikkiTavi (PHP)
If you like UseModWiki in PHP + its own nice features

LogiLogi (PHP)
Like Tavi + Sections and Multilanguage

Chiki (WebDav)
If you like easy ;)

[Kwiki] (Perl)
easy to install, modular

[WackoWiki] (PHP)
– Small, lightweight, handy, expandable, multilingual Wiki-engine. [WYSIWYG editor], [SafeHTML], easy installer, many localizations, email notification on changes/comments, several cache levels, design themes (skins) support, XHTML compliance, page rights (ACLs), page comments.

WikkaWiki (PHP)
A lightweight/easily customizable WikiEngine forked from the glorious WakkaWiki?

UseModWiki (Perl)
If Perl is your friend. This site runs UseModWiki Perl need not be your friend. If you don't have your own web server, and rely instead on free or inexpensive commercial servers, they are far more likely to support Perl than many of these other languages, alas.

My favourite is UseModWiki (for obvious reasons), but that's because it bests suits my needs for MeatballWiki, and if it doesn't, I can upgrade it so it will. It's also very configurable, so it also serves about a billion other people's needs, right up to the largest wiki on earth, WikiPedia, if you can call Wikipedia a wiki. (and you discount EverythingTwo).

If you want more specific answers, ask more specific questions. What are your requirements and intentions? -- SunirShah


3. Q & A

Are there any wiki clones that use UTF-8, to handle multiple languages and orthographies in UniCode?? -- JerryMuelver

Jerry, 'Tavi supports UTF-8. All you have to do is add $Charset = 'utf-8'; to your config.php file. You should be aware that there are problems with Netscape, however. See [Tavi:UTF-8 Text].

OddMuse (a UseMod descendant) can use UTF-8 (UseMod cannot, there is a "forbidden byte"). -- AlexSchroeder (No longer the case in UseMod v1.0) -- ChuckAdams
UseMod works fine with UTF-8 with some very slight tweaking; in particular, the field separator byte must be changed to 0xff, which does not appear in UTF-8. See UseMod:SupportForUtf8 -- BrionVibber

PwykyWiki will allow both UTF-8 entered naturally (if the browser allows it), and unicode codepoints to be entered using a {U+HHHH} syntax. These are even automatically converted to UTF-8 encoded hex for citaton URIs. -- SeanPalmer

TWiki (TwikiClone) has some UTF-8 support (still under development, though some sites use it already), and will ultimately handle Unicode normalisation and other difficult issues. It can already be used for languages where WikiWord support is not relevant (Japanese, Chinese, etc.). For a demo site running in UTF-8, see http://donkin.org/ubin/view/TestUTF8/TestUTF8 - the plan for UTF-8 support is at http://twiki.org/cgi-bin/view/Codev/ProposedUTF8SupportForI18N -- RichardDonkin

MoinMoin fully supports Unicode (and uses UTF-8 for I/O) since version 1.3.


I'd be interested in knowing how many lines of code the various WikiEngines are, if anyone has any of these figures handy (I am of the mind that the less lines of code, the better) -- BayleShanks

On that note, see Wiki:ShortestWikiContest.

LOC have never been a good measure for any purpose. The Wiki:ProWikiSoftware is currently [Oct 02] about 9500 lines of Perl. -- HelmutLeitner

Wiki:TheMythicalManMonth contrasts necessary complexity and accidental complexity. Accidental complexity comes from poor understanding of the real problem (or less often poor use of tools). Lines of code is an indication of ratio of necessary to accidental complexity. Assuming consistent style is used, I'll always bet on the shorter program being more readily hacked on. Oh! Look! TinyWiki is winning Wiki:ShortestWikiContest at 28 lines. Perhaps I'm baised ;) - ScottWalters

If the code style were "consistently obfuscated", one could probably cram UseMod's 5000 lines into 500. Would this make it more hackable? I doubt it.

UseMod:OddMuse has currently 3779 lines of Perl. This is actually less than UseMod itself (4044 lines of Perl). That's because I'm trying to accumulate positive FeatureKarma. The reason the UseMod descendants are so large is that UseMod is all-in-one. It has its own database, its own VersionHistory system, conflict detection, and a maintenance web interface. The 100 line wikis either don't have this, or delegate this to external scripts or external tools (CVS or RCS for versioning, MySQL database). -- AlexSchroeder

Technically, you're reducing FeatureKarma. Karma's something you're supposed to escape from, not accumulate.

 But Karma is restated as `what goes around, comes around' which is a restatement of `a man reaps what he sows'

This explanation is not on the point, at least not with Wiki:ProWikiSoftware which is also all-in-one. The difference of 6000 lines is due to just about 150+ features of about 40 LOC each. Do you want Slurp-protection? RCS-Versioning? Multi-Wiki-rc? Multi-Wiki-logs? Optional subpages and hierarchical pages? Multi-Wiki-change-notification? Multi-Wiki-session-analysis? Tables? HTML-Templates? Dynamic Hot-Spots-Display? ... things just add up. -- HelmutLeitner


So, one feature of most Wiki engines is VersionControl?. I'm wondering if there's ever been a Wiki engine that implements a branching-and-merging feature. That is, a user could branch a page and work on separately. Multiple users could work on the different branches, and merge back and forth across the branch tree. You could get some fascinating page topologies this way. --EvanProdromou

Yeah, I think that would be cool. See CommunityWiki:BranchingWiki (or the MeatballWiki page, BranchingWiki). -- BayleShanks

I think this idea is only appealing to software developers. It would be much too complicated for normal people and push them back. -- HelmutLeitner


Something more lightweight then a Wiki is EditThisPagePHP, which allows you to edit a single page, but does support wiki-like version control and diffs. It also has some interesting concepts like RSS support, trackback support, etc.


A WikiEngine designed specifically for CommunityBuilding?

I don't think that one can "design for community", because no-one can simulate communities in his mind. But ... ProWiki was developed since 2001 always responding to community needs of - in the end, currently - over 100 systems. The needs are very different, so ProWiki has become by far the most configurable and most flexible engine. It is neither the most modern nor the most polished one nor is it the simplest to install. But if some community comes and asks "can we do X?" then the chance is 98% that the features is already there or that it can be implemented with a minimum of effort. -- HelmutLeitner


See also:
Why is Mediawiki missing on this page? It's likely the most-deployed engine. (Sorry your spam filter won't let me post this as a comment.)
CategoryWikiEngine

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This page is read-only | View other revisions | Search MetaWiki
Search: