I suppose it is no secret that I am a little bit obsessed with wikis. I think that the level of collaboration available through the use of a wiki is superb and unparalleled. As you may know, I recently did a thorough review of a short list of wiki selections in a two part series.

In my unending quest for the perfect wiki, I have been playing around with wikis that seem to be more geared toward the corporate world. My most recent dip in the wiki pool took me to Twiki.

What intrigued me about Twiki is that it is CGI based, as opposed to PHP. I had to do some serious work to get this one to work on Bluehost, although that is NO fault of theirs, this is just a complex program. But now I am wiser, and that is always my goal in learning this stuff. We talk so much about being lifelong learners, and this is one way I am completing this goal.

This post will also serve as a bit of a tutorial as to how to make TWiki work on bluehost.

1. The first thing you must do is download the software from www.twiki.org.

2. I would highly recommend NOT using SSH to unpack the files. I typically DO use SSH since it tends to work so much better than FTP’ing. The problem is that the permissions were wrong, so when I first attempted my site (after fixing the next problem) it looked like heck. Turns out I had to change the permissions to the /pub directory to 755 recursively. Had I unzipped the package (or extracted the tarball) to my desktop in a directory and then uploaded it, I would have avoided this problem.

I did post to the TWiki support board (not sure if I can really call it a forum) and even I was a bit confused by the posting process. They noted in a follow-up comment that 755 might be a smidge unsafe, as the executable flag is not needed, and that they recommend 644. Would that I were to keep this program installed, heed their advice I would.

On a related note, this bug was relative only to TWiki, and I will continue to use SSH (secure shell access) and Putty for many years to come. I like the command line interface and control features.

3. I also had to change the file extension on everything in the /bin directory. I have to admit, this was a real pain in the neck. I felt like I should not have had to work so hard to get a wiki installation working. I began to seriously question whether it was worth it. After changing all the extensions, it worked.

I then had to get Bluehost to install the CGI::Sessions extension for me. I am not quite sure if this is necessary, but I ran across it so many times in learning about the Twiki install process that I decided to go ahead and have it there if I needed it. As I understand it, the CGI::Sessions would be necessary if I were using some sort of authentication system for logins and permissions. So now it’s there, and it gave me one more chance to be impressed with Bluehost. They really have been fantastic!

Since TWiki is a CGI based wiki, it typically cannot run in a root directory, so one needs to use an .htaccess file to properly redirect. I didn’t set this up since I had decided against Twiki, but there it is nonetheless. I will post a follow up with more information on making Twiki work with Bluehost, as there is a more thorough, manual way to do it.

You can see the basic installation here. Scratch that, I deleted it, decided it was too much of a security risk and I didn’t want to change all the permissions again. So Twiki is gone.

So, now that TWiki is has been installed, here are my impressions.

Overall, I am not terribly impressed. One limitation that is inherent to using CGI is the naming scheme. Everything has to be what they call “WikiWord” which means it is all one word, with little to no separation characters. So, a page that Wikispaces would call Cool+Ed+Tech+Stuff Twiki forces you to call CoolEdTechStuff. If Wikispaces didn’t add the + symbol for you, this would be a bit of an issue, but they do, so it is a seamless naming scheme. This applies to most of the hosted wikis that feature WYSIWYG/WYSIWYM editors. As I understand it, the reason behind the WikiWord naming scheme is that it lends itself to automatic inline hyperlinking. So if I were in the throes of document creation, I would not have to worry about manually hyperlinking back to the originating documents, provided I inserted the proper WikiWord name.

I am not sure why I am so interested in wiki offerings. I keep coming back to Wikispaces and Wetpaint, almost exclusively. I keep looking at Jotspot, wondering how it’s going to look once it’s fully integrated with Google.

I notice that David Warlick uses PMWiki. It would work well for me, but Wiki Markup language is so difficult for my young students, which contraindicates its use in my classroom (along with MediaWiki, etc etc). I keep going back to the WikiMatrix to see if anything new has surfaced. Maybe one day the wiki market will grow to one that is hosted and appropriate for kids.

I did get an email from www.helpingstudents.org (not linking) and I noticed that they simply use jspwiki, and I wondered what the benefit is. Seems like Wikispaces is a stronger wiki (not to mention WetPaint). My solitary gripe about Wetpaint is the limited amount of wiki space. I look at Wikispaces and see a little menu, and lots of editable space. The menu on the right on each Wetpaint is a little bothersome for me and my kids. I am hoping Kevin and those guys will consolidate the menu.

One major positive for WetPaint is the monthly (I think) status updates. I got a little email the other day telling me my wiki was 315th of over 100,000. That was nice to see, along with how many contributions I had made, and related other sundry information.

And so continues my obsession with Wikis. Part of the reason I continue down this road is because I feel like kids will be using Wikis in their jobs, and since the job market is changing so much, I think they need to learn about these now. I thought it would be fun for them to use one of the major players in the corporate wiki market, such as SocialText, Confluence, or Twiki.