I wrote a Wiki yesterday. It’s under 25k in one file. I tried blearily to explain to Berta what a Wiki was this morning, and I don’t think she was impressed by my description.
A Wiki is a way that you can easily create linked pages without using a lot of HTML markup. The appeal is that you don’t have to know the HTML tags, and a lot of the building of the pages is accomplished by knowing a few simple rules.
The example I gave Berta this morning had to do with headings. If you want to create a heading, you write the heading on its own line and prefix it with an exclamation point (!). The more exclamation points you use, the further “in” the heading is. Three exclamation points is an H3, for instance.
This wasn’t so impressive, but it’s the gist of the thing.
One thing that wikis do that make them a lot easier to edit is the way they create links. There are a few ways to make links on a wiki, and the most well-observed method is by using wikiwords. Wikiwords are written in CamelCase. CamelCase is usually a couple of words that are crammed together so that there is more than one capital letter.
Wiki software will turn any wikiword into a link automatically. The link points to a page that is specific to that wikiword. So anywhere you write the word “SoupKitchen”, a link is created that says “Soup Kitchen” that points to the SoupKitchen page.
If the page doesn’t already exist, the wiki will create a special link that lets you create that page. When the page is created, the link behaves as normal.
There are easy ways to use common punctuation to create links to internal and external sites, too. I won’t describe this in too much detail here because I already wrote a long thing about wiki syntax for my software, MicroWiki.
MicroWiki has a lot of similarities to the wikis that are out there. Granted, it’s not as fully-featured as some others (like pmWiki, which I really like), but it has a base set of functionality that is better than many wikis of its small size.
MicroWiki retains a history of changes for each page so that you can see the revisions. I may add support for displaying the differences between two versions. This would be nice because you can see what changed very clearly within a large page.
MicroWiki also supports required logins. This is not something I’ve been able to find on many wikis, since it’s not really in tune with the attitude of wiki software. The idea of wikis is that anyone should be able to come along and make changes and updates to the wiki. Well, that’s crazy. So I have an optional setting in MicroWiki that allows you to require that a user be logged in before they can make changes.
There isn’t a self-registration routine, so someone will have to create an account for a user that wants to log in. Each user has his own wiki page for his user account. That page contains the login information for that user. That way, I’ve managed to need only one database table.
MicroWiki supports minor edits and edit descriptions so that you can make minor tweaks without bumping old revisions out of the archives. With the descriptions, you can say what you changed so that others can know what to review.
You can specify global headers and footers for the wiki that are actual wiki pages themselves. This allows you to put an “edit” link on the bottom of every page, and show the title of the page at the top.
MicroWiki can stand by itself or integrate into a WordPress blog using the EzStatic plugin. I am planning on integrating the login mechanism into WordPress so that if you specify that option, your WordPress login gives you access to the wiki. That’ll be cool.
I’m just a little shocked that the project came along so fast. There are a few features of pmWiki that I’d like to throw in there yet, like the automatic generation of next and back links. There is still a bit to do, more than what I’ve already mentioned, but it’s fairly complete.
(Why not just use pmWiki? -It doesn’t integrate into WordPress cleanly.)
