Wiki Choosing Stories

If you have a story about ChoosingaWiki that you want to share, put it here:

I looked for a wiki to put up my net diary. The server already had PHP installed, so I thought it would be a good idea to install a PHP-based wiki. I watched the (long long) list of PHP wiki engines and tries to find what I was searching. I wanted a simple, maintainable, clean wiki. Most of the engines there were some kind of megalomaniac projects with all bells and whistles one could ever think of. Of the few that remained, three had their websites down, some were incredibly bloat, and some offered only databases as backends (I prefer to track my wiki in plaintext). The best I could find was a thingie which was made only of 3 scripts and 15k of code. I watched the code a little, and decided, yuck, this is not what I want to deal with.

So I once again got more evidence that PHP programmer attitude is bad enough to cause it pure waste of time to even quickly evaluate PHP software.

Then I turned to Python, which I know has a lot of competent programmers. I chose a wiki that seemed to be very traditional and which was used as a starting point of other wikis, so I ended at PikiPiki. It was one script to put into cgi-bin, and all the configuration was in the script file. Good. I had to change it in many ways to make it work well for me (my mother tongue is an inflected language so WikiWords are bad), but it was easy, fun and soon done.

I wish I had seen ChoosingaWiki a month ago [Oct 2000 -- it didn't exist in Sept], as I just recently went about choosing one myself to run internally at my company. Things that were important to me, in order:

From a short list of MoinMoin and WikiWorks, I chose WikiWorks. It has the most powerful WikiSyntax and feature set I know of, with WikiName aliasing, table support, inline HTML, file upload/download (handy for image inclusion, links to docs, etc.), history and diff, recent changes, all pages, etc. It is completely self-contained: uses the file system for persistence, doesn't require a web server, deployment consists of basically just a VisualWorks image and virtual machine, plus initial content directory tree (of course, to modify it I need the rest of the non-commercial VisualWorks development distribution). Setup with MoinMoin was real easy - good documented procedure - but I had to install Apache and Python, and MoinMoin's WikiSyntax is not as strong, and the distribution is binary (although there is a SourceForge project you can join if you want to modify it). WikiWorks could use more documentation and scripts on how to set it up; I basically had to figure it out from first principles (fortunately I had the SmallTalk development environment at my disposal to help with that :-) --RandyStafford

Please explain the binary nature of a set of Pure-Python modules; I'm real curious... :) -- JuergenHermann

Please instruct me as to which part of the standard MoinMoin distribution is modifiable source code - it wasn't obvious to me, but then I'm ignorant of Python. --RandyStafford

Everything! All files are plain text files. Just look in them. (a file ending .pyc is a compiled .py (compilation happens automagically when you import a module), but all the .py files are there) --MagnusLyckaa

OK, I think I see what's going on. In the MoinMoin 0.2 distribution there are exactly three files that match *.py* - _template.py, __init__.py, and wiki-moinmoin/moin_config.py. I had looked at these before, and none contains logic to respond to HTTP requests, etc. However, wiki-moinmoin/moin.cgi does. I didn't look at it before on the assumption that it was binary. Despite its name it clearly contains modifiable Python source implementing a wiki server. --RandyStafford

I plan to host one Wiki for now (CreationMatters at http://www.ourpla.net/cgi-bin/wiki.pl), and probably a few more over the next few years. This is not aimed mainly at programmers, and whoever comes will be discussing strategies (patterns?) of personal/social development (that's brief, but not complete/accurate).

1) I want connections with the core existing Wiki community. There's conversations on other Wikis that are relevant. To me that means InterWiki capabilities, and prefer compatibility with most of the original Wiki markup language.

2) Keep it as Wiki as possible. Prefer standard page that's plain, no ads, just one "logo" image. Avoid fancy features (logins, infinite versioning), especially those that will overwhelm NonTechiesNewToWiki?, and more importantly those that threaten WhyWikiWorks.

3) In reality unlikely i'll mess with the code, but there is a preference for FreeSoftware (for that and other reasons), and a preference for Wikis in Perl since i want to learn more of it (Python sounds like fun learning also).

4) Ideally i can move the data to different software later (something like WikiInterchangeFormat). Maybe i'm too worried about this. If there are a lot of users, and we all want to move, we'll find a way. Has anyone been seen MovingToAnotherWikiPlatform??

5) Non-"classic' features i do want: Edit collision detection. About a week of user-accessible backup on-site. I think. Alternatives to tabs. Maybe some more complete indexing features and search, but i'll know better once the thing has some serious page-building going on.

First, i tried ZwiKi -- It works and you can set one up free at ZopeDotOrg, so i tried it out. It brought me to face with this middle-layer language DTML -- you can write in HTML plus some dynamic stuff. ZopeApplicationServer is underneath ZWiki and is a content management system and seems like a powerful thing to learn. But i just ain't gonna need it! Text and optionally coding are enough for me.

As a user i am excited about what Zwiki offers now for, and in general the future development of, ClientSideWikiEditing?. But i'm betting that any critical features will make their way into most of the actively developed Wikis.

I kept looking at TwikiClone but it looked a little more complicated than might meet my keep-it-as-Wiki-as-possible needs, and i am not a corporate environment.

So i'm actually entering data on UseModWiki, let's be honest in part because i was able to download it and set it up myself on the Unix account at my ISP at 3 in the morning (for Twiki i would've had to get some info -- no biggie). There are plans to moderately extend versioning, which sounds good to me. And i actually might use the SubPage feature. --JohnAbbe

Mmmm, When we started we tried out JosWiki, I think because it was simple to set up , and still fully featured... But then It became popular in the company, I started making modifications to the Perl code to add named links, VSS file viewing access and a way to query our bug tracking system... During this time the wiki becaume a serious proposal to meet out department's Knowledgebase needs (and we are a huge company) and somewhere alongthe line TWikiClone was chosen. now the good thing is that TWikiClone has some roots in JosWiki, so the conversion was totally trivial. The largest amount of work was because I wanted to use VSS instead of rcs.

So TWikiClone on WinNT with IIS, VSS and blat are easy - I still have to clean up, and post my changes to them...

And some time next year we will be using the wiki for large bits of our processes. Very nice indeed --SvenDowideit

When I decided to experiment with using a Wiki to capture the random bits of information I accumulate during the natural process of doing my technical day job as a systems analyst and my main hobby as a radio amateur (M5KVK) I wanted a Wiki that I could run on a variety of platforms (Mac, Win32 and Linux) and was easy to setup and use without necessarily needing a web server. That drew me to SqueakWiki; particularly as it is written in SmalltalkLanguage, a language I have played with on and off for years.

Everything was very easy. SqueakWiki is built on SqueakSmalltalk and has the Comanche Web Server built in. Its text formatting rules are different from other Wikis such as this one, mainly in that it doesn't automatically create links from concatenated capitalised words.

I like it: I have only been using it for a few days, but I have already created over 50 pages. It doesn't have some of the fancier features, but it works for me as a personal Wiki. I am now starting to consider how I could extend it: such as embedding live web pages and RSS feeds.

Prior to using SqueakWiki I have been using TheBrain. This is a very good product, very visual, but is also very proprietary! Unfortunately, I can see no easy way of transferring the mass of information I have stored in TheBrain to my Wiki. --GarethHowell 

Recently, me and a few friends decided to start a science fiction-related wiki. Our requirements were specific. We needed an application that:

Unfortunately, points 1 and 2 ruled out MediaWiki. Our project manager suggested TWiki, but it's written in Perl, a language none of us knew, not to mention it may not be available on some shared hosts //(note: my fears proved to be unfounded)//. It had to be PHP. Oh well.

First stop, WikiMatrix. One wizard later, I had a tentative list of wiki software to evaluate.

For some reason, I begin with PmWiki. It looks clean - a good sign. Uses flat file storage, too, so point 1 above is pretty much guaranteed. But then I spend three long evenings adding plugins for the functionality I wanted. Configuration is done by editing a PHP script. Easy job for me, but not exactly comfortable. Besides, the resulting site feels rather cold and sketchy. Definitely not what we wanted.

Next in line, an engine I hadn't heard of before: WiClear? is a french wiki system with a twist. Namely, it has hierarchical pages instead of namespaces. Not sure how these will work out, but the other features look fine, and the theme system seems very simple. Unfortunately, the installation is framed with PHP warnings. Not too mention it ends up bombing with a series of MySQL errors (I knew flat files were better, he he) Oddly enough, the site works, but the administration panel does not. Too bad...

After looking around a bit more, I end up trying DokuWiki. This one has all the features we want built in (which means less plugins to install), including two MediaWiki features I happen to like, namely automatic thumbnails and table of contents. Also, while the syntax is a bit odd by comparison, tables are much easier to work with.

Long story short, I ended up deploying DokuWiki. No, it's not perfect. Themes are difficult to tweak, though very easy to install, the only available tag plugin is unsatisfactory and only an administrator can adjust the access control lists. But it allowed us to become productive very quickly, and later tweaks didn't even warrant a backup. --FelixPlesoianu

CategoryWikiImplementation

EditText of this page (last edited November 24, 2008) or FindPage with title or text search