Wiki Software Evaluation
Notes from JohnGoerzen's thoughts about various wiki engines.
Desired Features List
- Newbie friendly - make it easy for people to read and contribute
- Nice-looking, inviting themes
- GUI (pseudo-WYSIWYG editor)
- Intuitive use and language
- Power user friendly
- Markup language that is sensible
- Good management features for searching, renaming, copying, etc.
- RSS feeds and email subscriptions for individual pages or entire wiki
- Lists of wanted (pages that are linked to but don't exist) and orphaned (pages that nothing link to) pages
- List of backlinks
- Administrator friendly
- Upgrades are trivial
- Flexible security system for reading and writing
- Generally takes care of itself - "install and forget"
- Good anti-spam features
- General features
- File attachments that are versioned
- Categories or some sort of hierarchy can be defined by users
- Ability to search only within a particular category/section
- Ability to redirect people to new page after rename
- Even better: automatic rewriting of backlinks
Looked at it briefly.
- User list is stored in a single file.
- Can't search by category
- Can search by namespace, but there aren't checkboxes for it in the search screen; you must know the syntax.
- WYSIWYG is a plugin, as are categories.
- Lots of plugins to maintain, keep up to date, etc.
Didn't seem to have any real features vs. MoinMoin
Demo site: http://gitit.johnmacfarlane.net/
- Uses Pandoc for markup processing, so supports quite a few standard formats including Markdown, RST, LaTeX, and can export in even more
- Math support using texmath
- Clean and attractive default theme (resembling wikipedia's old one)
- Store in git or darcs
- integrated history viewer, so doesn't have ikiwiki's history viewing problem
- No WYSIWYG editor
- pretty light on features in general. Could be useful for a very simple, quick-start wiki, but lacks some of the features of the more established ones.
- Very beautiful and simple default theme
- Nice general feature set
- Only supports Mercurial for VCS.
- No WYSIWYG editor
- Not clear if it has anti-spam features
- No plugin system
- Awesome backend. Can checkout a git clone of a repo and use git's features to do a merge.
- Default markup is Markdown.
- Nice comments plugin for discussion pages, with RSS stuff for individual comments.
- Nice tagging system.
- Attachments versioned like anything else.
- History viewer isn't integrated; it's gitweb or ViewVC, and so ikiwiki themes don't apply to it.
- Is also completely complex and overwhelming for newbies.
- No "revert a page" button
- Compiles to static pages that are served up by web server. Makes ACL-like security impossible (or limited by what a sysadmin can do with Apache rules, and thus won't necessarily work after page renaming, and is harder to delegate to users)
- Lacks WYSIWYG editor
- Lacks simple email notifications and subscriptions
- Themes are lightweight and functional, but ugly. Doesn't seem to have a thriving community of theme builders.
- Obviously scales up to absolutely massive sites.
- I have never seen a wiki other than wikipedia that has any need for this though.
- Category system is very nice.
- Can generate sorted lists of pages in a category, has subcategory support, etc.
- Namespaces are available.
Good use of them at http://uesp.net
- Can restrict searching by namespace
- Lots of cons too; see below.
- Good spam prevention and supports recaptcha.
- Can't restrict searching by category
Searching is overall less capable than in MoinMoin.
- Namespaces are heavy-handed
- Have to edit config files to define them
- Bring with them other associated namespaces for discussion and the like
Not as easy as creating a category in MoinMoin
- Doesn't scale well to having dozens of namespaces
- Help is a broken link by default. Even the "editing help" links on the edit screen.
- Installing help is an undocumented step of copying help pages from mediawiki.org
- And you do this by "cut and paste" according to mediawiki folks.
Every time a new version of MediaWiki comes out, you have to cut and paste dozens of pages from mediawiki.org to your wiki, or else you'll have outdated help.
MediaWiki folks like it this way!
I remarked that "it is way too complicated for its own good. There are something like a dozen calendar plugins for it, some of which even are thought to work. The one that looked like the one I’d use had a 7-step (2-page) installation process that involved manually running SQL commands and cutting and pasting some obscure HTML code with macros in it. No thanks."
This is the wiki that I use for this site and for www.complete.org. We also use it at work. I have more experience with it than any others here. Have been using it since 2009.
- In general, follows the KISS (Keep It Simple, Stupid) principle
- Email receiving system
Fairly large user base and theme selection. Some are beautiful.
- Nice subpage support
- ACL security model is simple, predictable, and powerful, with optional hierarchical applications for subpages
- Built-in full-text searching. If you use Xapain, is indexed and blazing fast.
Xapian integration will support search inside PDF, OpenOffice, Word, JPEG EXIF, etc. attachments.
- Can index just current versions or full history of pages.
- Page templates to make it easy to create pages in a standard form.
- Since 2006, all upgrades can be accomplished with a simple shell command that takes about 10s per wiki.
- WYSIWYG integrated, using FCKEditor.
- One-click subscribe/unsubscribe to email notifications for a page, plus ability to set a list of regexps for such notifications.
- Jabber notification also supported.
- Global recent changes RSS feed, but no such feeds for individual pages
- User-definable categories
- Offline sync, but not as elegant or error-free as the ones backed by Git
- Large plugin libraries:
All sorts of other extensions are avialable at MoinMoinExtensions, such as parsers, themes, actions, formatters, etc.
Most of these are maintained within the default MoinMoin distribution, so you don't have to manually update tons of plugins or worry about version compatibility issues.
Has an awesome HelpOnMacros/MonthCalendar macro.
- Can also email things to the wiki, which get turned into wiki pages.
I have turned this into a personal tasklist and todo list. See my blog post about it.
- Can easily define arbitrary categories
- Automatic options in search screen to restrict to particular categories
- Logged-in users can create "personal bookmarks" -- adding links to the top of the screen
- Supports attachments, but their history isn't tracked. If it's deleted, it's gone.
- Doesn't use a VCS. FS storage is inefficient but not problematically so.
- Default themes are ugly and use language that isn't always newbie-friendly
- Its website is confusing and search is annoying because bug reports are on the official wiki
- Search only includes page titles by default (have to click the "text" button to get a full-text search, which isn't intuitive)
- ACLs could be more fine-grained. For instance, there is no ACL for attachments. If you enable attachments globally, then anyone with write permission to a page can add attachments to it.
- No "maximum attachment size" setting
- Though there is a maximum size for attachments in ZIP files
- Has anti-spam feature (Textchas). You come up with questions that people answer. Not as good at preventing spam as captchas, but work reasonably well.
- Has a despam feature to revert all changes from a particular IP.
No direct support for namespaces, but I think I may actually like its powerful subpages support better in a way. FindPage lets you restrict search to certain categories, but that requires action on the part of editors to make sure things are categorized.
We used this at work from roughly 2007 to 2009. We had several complaints about it:
- Upgrades were needlessly complex. Releases often had known bugs with LDAP that required local patching.
- Themes were unappealing and overwhelming
- It has a bunch of non-wiki things. These we didn't need and somewhat got in the way.
- Weird markup for verbatim sections and tables.
- Encourages people to put images outside the wiki's management in a wiki_up directory. Is never clear which images are in use. Provides a way to write images there, but none to delete them.
One nice feature was that when you rename a page, it could automatically rewrite all links to it.
TWiki / FOSWiki
- Supports namespaces -- calls them webs. Each one can have its own security settings.
- Has a WYSIWYG editor -- TinyMCE integrated.
- Uses a VCS backend.
- But the only supported VCS is RCS, and it's required!
- Supports conflict resolution
- Large plugin library
- Terrible upgrade process. Upgrading is a 9-step process, and some of those steps are non-trivial -- even for minor upgrades.
- There are way too many steps in the upgrade docs containing the phrase "manuall merge"
Markup is an inconsistent mix of HTML-style markup and more traditional wiki-style markup. Have to escape <, >, and sometimes & -- which are confusing for newbies.
- The only supported VCS is RCS!
- Lacks list of wanted pages
- Webs are named and act confusingly
- I don't think even advanced users will realize "web" means "namespace", let alone newbies
Example: go to foswiki.org, type something in the search box at the top of the screen, and it searches all webs. If you instead click search under toolbox and type something in, it searches only one web by default. There is no way to just "search these three webs/categories" as in Mediawiki or MoinMoin.
- Some operations are counter-intuitive.
Example: you can't delete an attachment; you have to move it to web Trash, page TrashAttachment. Which also isn't terribly fast to do.
- Attachments aren't secured by the security mechanism. If you know the name, you can get the file.
My blog posts: