The Wiki
I remember reading about the wiki so many years ago (mid 90s?). I wish my college Technical Writing classes would have included them. Wiki would have made the class far more interesting to those of us that were also CS majors, which accounted for a good 80%.
Only in recent times have I had a life situation that called for a wiki. Our office environment is one that uses a lot of shared documents. The company has long had a wiki, however it was an older piece of open source software that had long been abandon and left with many bugs. Since then, wikis have grown a slew of new features such as support for name spaces and moderation tools. With the time between project cycles, everyone agreed it was time for a new wiki. Knowing that we would have to grow and extend our wiki software in the future, I was most concerned about the design choices of the software itself.
Media Wiki
Since the infamous Wikipedia runs on Mediawiki, I gave it special consideration. Mediawiki is a PHP based webapp, and I like PHP. It had all of the features we were interested in, except one. After installing and exploring the software, I set out on my first task: modify the wiki to use ldap for authentication. I started off on the LDAP Authentication page on the Mediawiki website. I expected it to take no more than an hour or two, but this task consumed far more of my time. The progression of the code base and the fact that ldap support was not officially supported lead to various conflicting files and instructions for different versions of the wiki. I do have to give Mediawiki credit, it had a nice clean container class setup for overriding authentication. Regardless, after a full day of sorting through diff conflicts and digesting docs, I stepped away from the project to clear my head. Before I got back into the code, a co-worker had setup a copy of another wiki, complete with full ldap support. This brings us to the next wiki of discussion – Flexwiki.
Flexwiki
Flexwiki appealed to many of our developers because it is written in ASP. More specifically, Flexwiki is written in C#, which many of our developers like even more. Flexwiki also supports its own scripting/macro language called Wikitalk. Flexwiki is actually one of Microsoft’s first releases as part of the new shared source initiative.
Most wikis aren’t pretty, but I must say that Flexwiki is down right ugly. I found the colors and layout annoying and the interface non-intuitive. The markup language quickly became confusing and overly complicated. When wiki markup reaches a point where it was more difficult to read than html, we’ve gone too far!
My biggest concerns came when I went to validate Flexwiki’s html. Even with a transitional doc type declared, Flexwiki fails validation. It is common to see pages fail validation because s user entered data containing invalid markup; but in this case the offending html code belongs to Flexwiki itself. Flexwiki is definitely a Microsoft product.
But, we chose to use Flexwiki anyway. You might think the story ends here, but it doesn’t. Not long after we settle in on Flexwiki, another project came along requiring the use of of Wiki. Once again, I went on the wiki hunt, this time with different results.
PMWiki
I started going through demos on OpenSourceCMS. I saw the PMWiki demo running and almost disregarded it as to simple looking. I happened to take a second look and noticed a reasonable feature set, so I downloaded it. By chance, of the three wikis I pulled, PMWiki was the first wiki I decided to test. That’s when things got good.
PMWiki is another PHP based wiki. The code is clean and simple. More importantly, it’s loaded with features just waiting to be enabled. I felt like a kid in a candy store. Within half an hour, I had more neat stuff configured in PMWiki than I did in a full day with MediaWiki. But, for this project, I had one big lingering task.
Next, I needed to link PMWiki’s authentication with an existing vBulletin community. Because I had easy access directly to the vBul database, I thought the hard part would be working within PMWiki itself. I was completely wrong. In less than an hour, I had PMWiki figured out and and the code written. However, I got hung up on vBul’s authentication system. I expected the passwords to be encrypted with MySQL, since this is rather common. Instead, vBul uses a combination of crypt functions. Finding this out took hours. Navigating through the vBul source code hurts my brain. I was jumping in and out of subdirectories chasing down includes. Instead of using native PHP syntax, the vBul developers created custom functions to use like operators. I finally found the three separate methods used for encrypting passwords and managed to complete my authentication function in PMWiki. We now have a fully operation battle station.
To take things a step further, I created a group on the vBul forums for wiki admins. I then modified PMWiki to only authenticate users in that group. Now, a moderator can easily manage who gets to edit the wiki from within the vBul control panel. The end result is very satisfying.
Conclusion
I don’t want to put to dark a note on Flexwiki, as it might become a very interesting piece of software. Mediawiki is, without a doubt, a very well refined application. However, for an easy, lightweight, and powerful PHP based Wiki solution – I highly recommend PMWiki.