Webiki is a plugin for Movable Type designed to support automatic linking in the manner of a Wiki. Each entry can be tagged with Webiki Words using the “Keywords” field of the entry. Use of a Webiki Word in another entry causes the Webiki Word to be replaced by a link to the post with the Webiki Word in its keywords with link text generated from the entry title. Some of the common Wiki Word extended syntax is supported as well. Webiki operates as a global filter.
If you want to cut to the chase, choose one of these topics:
All of the links to other posts on this page were generated via Webiki.
Webiki is available for Movable Type 3.2 and 4.2 (untested with 4.1).
Changes from previous release
- Fully integrated with MT 3.2. There is no longer a seperate configuration page, everything is done through the plugins settings page.
- Glue and affix settings.
- Sorting settings.
- External links.
- Extended syntax for finer control over multi-link output.
- Many more MT Tags.
- Automatic database table creation.
The 1.1.6 version is identical to the previous except for working with MT 4.2.
Webiki is not designed to be a Wiki. However, I wanted certain Wiki style features for use in Movable Type in order to support a small group of authors building a semantic web. Based on the experiences of pure Wikis, I preferred the Movable Type author system. Non-authors can contribute via comments which authors can then incorporate in to the posts as desired. This is similar to how MySQL handles their online documentation and that seems to work the way I want to.
Compared to other tags based plugins
There are a lot of keyword / tag plugins for Movable Type. Beyond the inertia of the fact that I built my first version before those were available, there are still several key features Webiki provides that aren’t available in any other tag based plugin. The primary one, however, is the ability to use the tags to create links in a post. As far as I can tell, no other tags plugin supports that, they only support access to the tag space via template tags. For me, however, in-post use is the base feature of Webiki, the essential purpose of the plugin. After that comes the ability to handle multi-target words and then (oh, finally I have it working!) the ability to reference external URLs by webiki word. After all that, yeah, it’s nice to be able to use template tags as well.
Other Wiki-ish issues
One of the other reasons I built Webiki instead of using a Wiki is text formatting. I’ll admit it, I’ve become heavily dependent on Textile. I’ve looked at Wiki style formatting and I find it worse that just using HTML. Why anyone would write MT plugins to emulate that is beyond me.
None of the Wiki implementations I looked at made it easy to drop in text filters. I figured I could easily live without the open style of a Wiki as long as I could pull a few Wiki features in to Movable Type. And here we are.
Some of the other plugins I use are
- WikiVar, which provides the equivalent of Wiki variables and functions
- FormatStack, which allows me to combine multiple text filters in to a single text filter. So, I can create a filter that does a WikiVar pass, then a Webiki pass followed by a Textile pass. This enables me to use Webiki and Wikivar without modifying Textile (which is what I used to do) or changing all of my templates. Moreover, I can vary this on a per entry basis.
Why did I go with Wiki words instead of arbitrary keywords? It’s primarily a scaling issue. If one accepts arbitrary keywords, then there are only two implementation choices:
- Create a huge RegEx with every single keyword in it every time, which means loading every entry from the DB.
- Do a transforming pass over the text for every keyword.
Both of these will become server performance bottle necks once the number of posts with keywords grows sufficiently large.
On the other hand, by restricting the potential set of candidates for transformation to Wiki style words, I can run through the text with a single RE and check the captured text against an indexed DB table. A bit of caching and the performance should be reasonable except for very large DBs (note that the performance cost grows only with the DB search cost over the entire set of keywords. A good DB should keep this to be roughly logN instead of N).
Trackback URL: http://blog.thought-mesh.net/solidwallofcode/mt_projects/webiki.php/ping