Advanced search

Why I switched to PmWiki

PmWiki facts

  • flat file data storage. No database required
  • Lightweight and fast, yet feature rich
  • very powerful markup features
  • built-in inclusion and transclusion features, dynamic page lists and more
  • extensible by cookbook recipes
  • low requirements, should run on most webhosts, regardless of server software and PHP version (although, PHP 4 is required).

Switching to another software for the exactly same purpose is not something you normally do just for fun, because it means work, sometimes a lot of. Converting a blog, forum or any other site from software package A to package B is rarely a smooth and quick experience. Switching from one Wiki software to another one can be a pain, because there really is no such thing as a "Wiki standard" :) Every system follows its own philosophy and, while partially more or less standardized, the markup features vary greatly among different platforms.

It might be easy for normal pages that are just using standard markup, but as soon as you add complexity (like inclusions, templates, groups/namespaces/categories, the transition won't be smooth.

Said all that, it should be clear that the decision to change the publishing platform is not an easy one and should be well considered.

So why switching then?

The main reason is simple: Performance.

Even though I'm running this on a pretty fast server (a dual Xeon @3GHz, everything native, no virtual machines, highly optimized with nginx, FastCGI via domain sockets, eAccelerator PHPCache and optimized MySQL with query caching active), performance with MediaWiki was mediocre at best. It wasn't the web server, it wasn't the database, it simply was the script execution time.

Now, I know that MediaWiki isn't exactly slow. In fact, it might very well be the most scalable Wiki software you can get, but this comes with a price. MediaWiki is designed to run Wikipedia, it is optimized to serve many, many, many requests to a high number of anonymous (= not logged in) users. And it does it well, but all the overhead needed for efficient caching, a database design that scales well for millions of pages makes the code more complex, thus more time consuming for small sites. My site won't ever have more than maybe a few hundred pages, so I do not need a solution that was designed to handle millions.

Also, I found MediaWiki hard to maintain and upgrade. While the main software didn't cause any issues for more than 2 years, some extensions did cause more than a small headache. Not the fault of MediaWiki either as unmaintained extensions or plugins are always a pain but I didn't want to invest the time to deal with some extensions after every update of the main software. Also, some extensions, no matter how simple they are, seem to degrade performance even more and the same applies to custom skins.

PmWiki's implementation approach is totally different. It is designed to be simple and easy to maintain, yet it does not lack the important features:

Some highlights

  • extensible Wiki markup - all standard features are there and additional markup features can be added easily.
  • Dynamic page lists - some kind of primitive script language to generate list of pages. One usage scenario: create a blog-like index of pages with teasers and a "read more" link.
  • user authorization and -permissions for reading and editing pages. Also, user groups are possible. If this is too complex, there is a simpler password-based page protection scheme.
  • Powerful method to include pages or part of pages - it is also possible to pass variables to included text segments. This allows to mimic the template system known from MediaWiki.
  • Simple HTML cache - stores the HTML "compiled" version of the markup for faster page retrieval. Works for both anonymous and authenticated users. For high-traffic sites, additional cache methods are available as custom recipes (=addons/plugins/extensions whatever you may name it).
  • Simultaneous editing. Don't overwrite changes done by someone else while you were editing a page.
  • Wiki groups, categories (not the same as categories in MediaWiki though, PmWiki categories work more like a tagging system), group header, -footer and -home pages.
  • Group customization - for example, a Wiki group can have its own skin/template.
  • Wiki trails for easier navigation in a group of related pages.
  • File attachments, organized per page or per group.
  • Many, many, many custom recipes for adding additional functionality. Most of them are very easy and straightforward to install. From a blog up to a simple CMS, there is something for almost every purpose.


Author: admin Last modified: Friday, October 29, 2010 at 12:40 CET

Category: Main?

Page generation time: 0.112 seconds