Wascally wabbit. MediaWiki can be “coaxed” to do a lot.

The developer community spawned by MediaWiki continues to deliver new ways to extend the application in a lot of different directions. The community resembles the one that has grown up around OS Commerce. Both MediaWiki and OS Commerce are PHP-based applications with scores of implementations. Neither of them were intended to be general purpose development platforms. Both represent a specific need that a more general website may incorporate rather than doing it in a more proprietary way. Where OS Commerce has become the center of many web consultancies, MediaWiki has become the real core of many sites.

OpenWetWare is a good example. We tend to currently define ourselves as a ‘Wiki’. The collaboration afforded by the data model in many ways sometimes becomes an end in itself. Fortunately, MediaWiki is malleable enough to allow a good deal of growth as many sites change from being a Wiki to becoming more of a general web site for a specific class of content or collaboration.

One technical difference between OS Commerce and MediaWiki is the way OS Commerce extensions don’t differentiate between extension modules that require the core code to be patched and those that do. In MediaWiki, it’s more-or-less assumed that if a specific internal capability needs to be exposed, the core class method within MediaWiki within which the capability is implemented can be added to the list of internal ‘hooks’, pending review by the core MediaWiki developers. This means that the core MediaWiki class method in question will seamlessly call into a developer-defined PHP method or function do it’s thing, then post a return code that will modify the way the core class method internally handles the result.

An example of this is the way the personal navigator links appear in the top-right corner of all OpenWetWare pages. If a user enables the “Lab Notebook” option inside of the preferences section, the list of options will have a new “Lab Notebook” link added to the end. We’re soon augmenting this to allow a member to join an IGEM team and have the an icon that immediately connects them to their team’s lab notebook. No core development is done. We don’t risk complicated patches to the next MediaWiki revision to make sure the link keeps on working. It’s clean.

We use these “hooks” in several other places. They’re pervasive in the way they change MediaWiki’s behavior. Unlike the MediaWiki API, a hook can change the way MediaWiki works at a very deep level. We can implement checks on every page create/read/update/delete opertation. We can monitor how pages are changed. We can synchronize these changes with external applications.

Steps like the formal support of these hooks by MediaWiki makes the use of the application for more things than it was originally intended tantalizing. I worked on Lotus Notes (now IBM’s product) for several years. Ray Ozzie, the lead developer of Lotus Notes and now Bill Gate’s heir apparent as Chief Architect for Microsoft, implemented a similar feature in Notes in 1993. The reason was to allow security vendors to implement their own proprietary login extensions that would allow Notes to “play nice” with other enterprise applications already using their products. RSA was one of the first companies to step forward to use the functions.

What we found was that the most technologically astute and experienced developers took advantage of these hooks. The rest of the marketplace continued to clamor for a radically simpler way to interact with Notes data and processes. As a result, a very small percentage of all third-party and enterprise applications never benefited from the very deep API. There are too many reasons this is the case to go into here.

Hooking applications like this can be compared to modifying hardware interrupt handlers. The consequences of doing the wrong thing can be the infamous “white wiki page”. Granted, this can also be caused by sloppy writing on any MediaWiki extension, but it’s much more likely to happen when using hooks.

The OS Commerce extension module-writing community handles some of these concerns another way. To avoid having users edit PHP code, a version of OS Commerce, OS Commerce Loaded, was created. In this version, many of the most frequently requested extension modules were added to the core product. Clients simply deploy “Loaded” and only enable the modules they’re interested in. The core OS Commerce changes are still done, but by the community.

Where am I going with this? MediaWiki holds out the possibility to developers of infinite extensibility. But, because of how it’s done, this really hasn’t proven to be practical. Are there things that can be done with MediaWiki that may not be practical to do? It might be more useful to consider how MediaWiki can be integrated into a framework or methodology that allows it to continue to grow in a sustainable manner.

Render from MediaWikia that which is relevant only to the Wiki.