YK: Chapter 11: Extensions

11 Extensions

A crucial part of the MediaWiki system is the plugins, or extensions, that have been developed to be added to the MediaWiki core application. Over 1,500 publicly-released extensions exist in some form currently; though many of these are obsolete or redundant, and many never fully worked in the first place, so the number of extensions that could conceivably be used at any one time is probably closer to several hundred. Extensions in MediaWiki cover a very wide range of functionality. Some of it is rather essential functionality, which could easily belong directly within MediaWiki but was never added for one reason or another. An example is the Cite extension, which defines tags that can be used to show footnoted references; it’s heavily used on Wikipedia, and there’s no strong reason why it’s not part of core MediaWiki.

Almost all MediaWiki installations include at least a few extensions; Wikipedia uses dozens of them.

The core MediaWiki code is structured in a way that makes it easy to install extensions, and develop them: the key element is the widespread use of hooks. Hooks are lines in the code that outside functions can register themselves to be called at. When a hook runs, every function that has registered itself with that hook is called, and each one can then perform its own actions. A simple example of the use of hooks would be an extension that displays ads on each wiki page. The extension would most likely register with one or more hooks in the code that are called when the the display of the page is generated, in order to add its own snippets of HTML to the page. The big advantage of hooks is that they let extensions run without the administrator having to modify the core MediaWiki code ­ something that makes installing and upgrading the code much easier.

Some extensions define their own special pages; some define their own parser functions, tags, behavior switches, etc.; and some add their own tables to the database. The more involved extensions may do all of these things: use hooks, add tables to the database, define special pages to (in some cases) display and modify their data, and define various commands, like parser functions and the rest.

Finding extensions

This book covers a fairly large number of extensions, but it doesn’t cover all of them ­ and the “ecosystem” of extensions keeps changing, with new extensions being created, others becoming unnecessary due to changes in MediaWiki, and others becoming unusable as they stop being maintained. So it’s important to know how to find extensions, and how to determine which ones are useful.

The site mediawiki.org is the main resource for finding out about extensions. Every extension is meant to have a page there, so you can do text searches to find specific functionality you’re looking for. You can also use the “Extension Matrix”, which is actually a collection of pages, which hold different views of the full collection of extensions:

https://www.mediawiki.org/wiki/Extension_Matrix

If you do find an extension, it’s useful to know whether it will work on your system. There are a few clues you can use for that. Every extension page should have an infobox, listing important information about that extension. One of the fields is “Status”, which can be either “Experimental”, “Unstable”, “Beta”, “Stable” or “Unknown”, with “Stable” of course being the preferred one. This status is usually just set by the extension’s authors, though, so it may be out-of-date, and it may not have been reliable in the first place.

Extension pages usually also list what versions of MediaWiki the extension is compatible with. This information can again be out of date (especially if it reads something like “MediaWiki 1.11 and higher”), but it can also be useful information.

A good way to check the viability of an extension is to look at its talk page. If the extension hasn’t worked with versions of MediaWiki from the last two years, there will probably be at least a few messages to that effect. You can also get a sense from the talk page of how committed the authors or maintainers are to maintaining the code and supporting users.

Conversely, if there are no or few talk-page messages, that’s quite possibly a sign that people don’t find the extension useful (or comprehensible).

Finally, whether or not an extension’s code is contained on the MediaWiki Git repository is to some extent, for reasons of both cause and effect, an indicator of how well-maintained it is.

Installing extensions

Once you’ve found an extension that you want to use, the next step is of course to install it. Many applications make it easy to install extensions or plugins, directly from within the user interface ­ that includes both consumer applications like Firefox, and server-side applications like WordPress. MediaWiki, unfortunately, is not one of them ­ code has to be downloaded and installed manually. Adding a simple extension installation system to MediaWiki is something that many people have talked about, including both users and developers, and there have even been a few attempts to create such a system, but none of them have worked out yet. Hopefully such a thing will be created before too long.

So for now you will have to get the code for each extension yourself, in one way or another. How you do this depends on the extension, as well as on your system. Until 2012, MediaWiki and most of its extensions were stored on a repository that used the version-control software Subversion, otherwise known as SVN. In 2012, MediaWiki moved to a repository that uses Git, an alternate version-control system. Most of the MediaWiki extensions have moved as well, including nearly all of the actively-maintained ones. Still, a few extensions remain on SVN, and there are some extensions whose code is elsewhere ­ hosted with GitHub, Google Code or SourceForge, or in many cases (though this is not recommended), directly on the extensions’ wiki pages on mediawiki.org

If you have Git on your server, and the extension you want to install can be downloaded with one of those, then that’s the ideal way to do it. If you don’t have Git and thus can’t automatically download an extension, there are a few alternatives. One is to get the extension as part of a package or bundle. There are several bundles of MediaWiki extensions; of special note is Semantic Bundle:

https://www.mediawiki.org/wiki/Semantic_Bundle

It’s a package of around 15 extensions, based around Semantic MediaWiki. Many, though not all, of the extensions described in detail in this book are contained in Semantic Bundle.

Other packages of extensions include:

BlueSpice (https://www.mediawiki.org/wiki/Extension:BlueSpice)

semantic::apps (https://www.semantic-apps.com/en/Main_Page)

Besides downloading packages, you can also usually download extensions directly. One easy way to download extensions was via the “Extension Distributor”:

https://www.mediawiki.org/wiki/Special:ExtensionDistributor

It’s a page on mediawiki.org that creates a downloadable file on the fly, for any extension that’s in the SVN MediaWiki repository, and any applicable version of MediaWiki. However, for most extensions, these files represent a random snapshot that may not actually hold a working set of code (for instance, if someone made some bad change to the code right before the snapshot was made).

For extensions on the MediaWiki Git repository, though, Wikimedia provides a standard web-based Git code-review tool, called Gerrit, which lets you download a “snapshot” version of the code at any moment in time, including the latest version. This is a very convenient feature. This book won’t get into the details of Gerrit, but it’s a powerful tool for dealing with versioned code, if unfortunately not always the most user-friendly.

Finally, some extensions, especially ones not hosted on a MediaWiki repository, provide a downloadable file directly.

For the next part of this chapter, we’ll go over some of the useful MediaWiki extensions that didn’t fit in anywhere else in this book. This is far from a comprehensive list.

Gadgets

“Gadgets” is one of the extensions that come pre-bundled in MediaWiki. It lets an administrator define pieces of JavaScript that users can then make use of, usually for help with editing or other wiki tasks. You can see the full list of gadgets installed on any wiki by going to that wiki’s Special:Gadgets page, which lists all the gadgets and a brief description of each.

To install a gadget on a wiki, if it already exists on another wiki, go to that wiki’s Special:Gadgets page, click on the gadget’s “Export” link, and follow the instructions.

Any user can then use any installed gadget by going to the “Gadgets” tab within their Preferences page, checking the gadgets they want installed, and hitting “Save”.

There are many gadgets defined; two notable ones, both available on Wikipedia, are:

Navigation popups ­ lets users see the top contents of a page, and a menu of action items for that page, when they hover over a link to it. (This functionality is also available via an extension, “Hovercards” (https://www.mediawiki.org/wiki/Extension:Hovercards).)

HotCat ­ provides autocompletion when adding or editing categories for a page.

You can read about the Gadgets extension here:

https://www.mediawiki.org/wiki/Extension:Gadgets

There is a plan in place to make the installation of gadgets more automatic, via a central repository of gadgets ­ this may happen sometime in 2014. You can read more about this effort here:

https://www.mediawiki.org/wiki/RL2#Gadget_Manager

[]

WYSIWYG editing extensions

Every software has its weaknesses, and for MediaWiki, there’s very little question what the number one weakness is: the lack of a good WYSIWYG editor. WYSIWYG, which is pronounced "WIZ-ee-wig" and stands for "what you see is what you get", simply means that the content, when being edited, looks identical, or nearly identical, to how it appears when being viewed. This has been the standard approach in word-processing applications, like Microsoft Word or Google Docs, for decades; but for wiki applications, including MediaWiki, the track record is a lot spottier.

In reality, true WYSIWYG editing is impossible for MediaWiki, because its wikitext can include template calls and parser functions, two scripting-like features that, when displayed, can take almost any appearance ­ there’s no way to mimic that display in the editing screen while still making the contents editable.

A WYSIWYG-style editor for MediaWiki, then, would have to take a split approach: true WYSIWYG for regular wikitext (including handling of bold, italics, headers, tables and the like), and some alternate approach for template calls, either by keeping them as straight text or by using some helper mechanism, such as forms, to let users add and edit them. (The Semantic Forms extension, discussed in detail in Chapter 17, provides a form-based approach for editing template calls.) Such an editor might better be described with the alternate acronym WYSIWYM, for “what you see is what you mean”, which implies a looser connection between what’s on the editing screen and what shows up on the page, though changes in the display are still done via the interface instead of by writing in syntax. Though it’s less well-known, WYSIWYM is a standard approach for word-processing software; this book was in fact created with a WYSIWYM editing tool, LyX.

There’s another complication when trying to implement WYSIWYG ­ or WYSIWYM ­ editing for MediaWiki, which is that the rules for MediaWiki’s wikitext parsing have never been fully defined. Yes, we know that two single-quotes around text means italics, and three means bold, but what if a line of wikitext contains, say, a string of three single-quotes, then some text, then four single-quotes, then some other text, then five single-quotes? Currently, the handling for these kinds of cases is not precisely defined. The MediaWiki parser at the moment is an amalgam of rules, exceptions and counter-exceptions, and for a WYSIWYG editor to match the exact behavior of MediaWiki’s parser in all cases would be quite difficult.

So, there are two big obstacles to getting such editing working in MediaWiki: scripting-style elements, and the lack of well-defined parsing rules. Still, there are some extensions that try to achieve it.

Until 2012 or so, the most well-known, and popular, WYSIWYG solution for MediaWiki was FCKeditor. FCKeditor was a general-purpose WYSIWYG application for web editing that was created in 2003 by Frederico Caldeira Knabben (hence the name).

There have been two MediaWiki extensions that support FCKeditor, both called "FCKeditor": one that was created in 2005 and was maintained until 2007; and the "official" FCKeditor extension, which was created in 2007 by the FCKeditor team. This official version is the one that has been widely used. FCKeditor itself, though, is a defunct application: in 2009, development on it ended, and its developers forked the software to a new application, called CKEditor (which apparently stands for "Content and Knowledge"). In 2011, the developers decided to stop maintaining the MediaWiki extension, on the grounds that FCKeditor is obsolete. The FCKeditor extension already doesn’t work with more recent versions of MediaWiki, and seems doomed to become increasingly incompatible. There is an extension that supports CKEditor, appropriately called "WYSIWYG", which is part of the SMW+ software bundle. The development and maintenance of it, too, appears to have stopped, however (see here).

In any case, the FCKeditor- and CKEditor-based extensions share a common problem: they trip up when dealing with too much wikitext. Using any of them to edit a template page, for instance, will usually destroy the page beyond recognition.

VisualEditor

There’s bright news on the horizon, though, with the VisualEditor extension, an ongoing project by the Wikimedia Foundation to create a true, built-in WYSIWYG/WYSIWYM solution within MediaWiki. This project is even more ambitious than it sounds, because VisualEditor is meant to be a standalone utility, that can be used by other web applications like WordPress.

Work on the VisualEditor extension began in May 2011, by a team consisting of some of the WMF’s most experienced programmers. In July 2013, VE was made the default editing tool for the English-language Wikipedia, in a massive test of the software. Users experienced problems, however, with both slowness of loading time and occasional errors in the output, and after two months the old, standard editing was restored as a default, and VE became an "opt-in" editor instead. Over December 2013 and January 2014, it became the default, "opt-out" editing option for most of the small and mid-sized language Wikipedias, a situation that continues to this day.

[]

Figure 11.2 The row of tabs in the Portuguese-language Wikipedia (pt.wikipedia.org)

Figure 11.2 shows the row of tabs for the Portuguese-language Wikipedia; "Editar" ("Edit") brings the user to the VisualEditor interface, while "Editar código-fonte" ("Edit source code") brings the user to the standard editing textarea.

[]

Figure 11.3 VisualEditor interface for editing a link

[]

Figure 11.4 VisualEditor interface for editing an infobox template

Figures 11.3 and 11.4 show different aspects of VisualEditor in use, on the same article in the English-language Wikipedia: the standard editing interface, here used to edit a link (note how similar VE’s display looks to standard MediaWiki page appearance), and the interface to edit a template call, here for the main infobox for the page.

VisualEditor has remaining problems in terms of speed, accuracy and browser coverage ­ at the time of this writing, Internet Explorer is not supported at all (the plan is to support IE 9 and higher). Nonetheless, it seems safe to predict that VisualEditor will become the default editing tool on the remaining Wikipedias ­ including the English-language one ­ within the next few years.

As for the usage of VisualEditor outside of Wikimedia wikis, at the moment it’s minimal but growing. The page for the extension currently states, "Use at your own risk; it’s not ready for production deployment except for experts!" That’s in large part because the development of VE is tightly coupled with development on core MediaWiki. However, there may be a stable release of the extension by the end of 2014.

You can read more about VisualEditor and its current status here:

https://www.mediawiki.org/wiki/VisualEditor

SocialProfile

Social networking in the enterprise is big business, with lots of companies wanting to add replicas of Facebook and the like to their internal network. Social networking can in theory encompass a lot of different features: messaging, user profiles, user groups, blogging, microblogging/”status updates”, and so on. There are some that MediaWiki already has natively; talk pages are arguably one example.

The SocialProfile extension adds a variety of additional social networking features, and it has a number of spinoff extensions that add even more. These extensions were all originally developed for ArmchairGM, a site that was purchased by Wikia in 2006, and the code for most of them was made public in 2011.

The SocialProfile extension family is in somewhat of a messy state at the moment: not all of the extensions work well with the latest versions of MediaWiki, and the distribution of functionality across the various extensions seems somewhat haphazard ­ there are currently 21 extensions tied in with SocialProfile, many of which are very small and look like they could be merged in with others. Still, there is an effort in place to improve all of these extensions, and some wikis have found the SocialProfile functionality useful.

Here are the main features of the core SocialProfile extension:

User profile ­ a wizard lets users easily create a detailed user profile, including uploading an avatar image that is then used in discussions.

Public and private messaging ­ users can write both private messages to one another, and public messages on a shared “user board”.

Friending/”foeing” ­ users can publicly specify the other users that they know.

User status ­ users can set their current status, and users’ status history is preserved, allowing for Twitter-style microblogging.

Rewards system ­ you can assign points to different actions, like editing a page and friending someone, and then set ranks that users are publicly given when they reach a certain number of points.

And here are some of the additional SocialProfile-based extensions:

BlogPage ­ lets users create (non-wiki-page) blog posts.

PollNY ­ lets users create polls.

QuizGame ­ lets users create quizzes.

VoteNY ­ lets users vote on articles.

SiteMetrics ­ shows administrators various metrics related to usage of SocialProfile tools.

You can read more about SocialProfile, its current status, and all its related extensions here:

https://www.mediawiki.org/wiki/Extension:SocialProfile

UrlGetParameters

UrlGetParameters is an extension that can read and display the values of parameters from the URL query string. For instance, if the URL for a wiki page contains “&abc=def”, you could have the following call on the page:

{{#urlget:abc}}

...and it would display “def”. It also works for array values, so that, if there’s a string like “vegetables[1]=cauliflower” in the query string, the call {{#urlget:vegetables[1]}} will display the right thing (“cauliflower”).

UrlGetParameters isn’t usually necessary, but at times it can be very helpful, because it lets wiki pages pass information to one another. For instance, you could create a page that functions as a “wizard”, guiding users through a list of choices and offering them advice based on their inputs. The user’s inputs can be embedded in the query string via either links (the #fullurl parser function could help), or a mini-form (the Widgets extension could be used for that ­ see here). Then, the resulting page, which could be the same page or a different one, could use #urlget, in conjunction with #if or #switch from ParserFunctions, to display the right text.

The #urlget function can also be used in conjunction with Semantic Forms, especially with SF’s “run query” option (see here), which similarly can be used to display a wizard.

For more information about UrlGetParameters, see:

https://www.mediawiki.org/wiki/Extension:UrlGetParameters

Ratings extensions

People have become used to being able to provide quick feedback on content on the web, whether it’s “liking” a post, giving a thumbs up or thumbs down to a comment, rating a movie, etc. So not surprisingly, tools exist for doing the same within wiki pages. Such ratings extensions are always somewhat awkward in a wiki, though, because the content can change at any time. What if a page is poorly written, and you give it a low rating, and then the next day someone rewrites it and makes it a lot better? You might be able to change your rating at that point, but until you do, your rating is a meaningless metric that’s just confusing.

(To be sure, in many cases blog and social networking posts can be rewritten too, making votes on such pages awkward as well ­ but wholesale rewriting of a post is rarely done.)

There’s the added awkwardness where it may not be totally clear whether users are supposed to rate the page, or the topic that the page applies to ­ like in a wiki page about a restaurant. This is the same confusion that can affect commenting functionality on wiki pages (see here).

Nonetheless, there are various ratings and article feedback extensions, and some have been considered useful in some circumstances. Here are a few of them:

ArticleFeedbackv5 (https://mediawiki.org/wiki/Extension:ArticleFeedbackv5) ­ provides users with a simple interface, asking “Did you find what you were looking for?”, with a text box to allow additional feedback. This extension is used on a small percentage of articles in Wikipedia. It replaces the now-defunct “ArticleFeedback” extension, which was more complex, letting users rate pages on a variety of metrics, like “Objective” and “Well-written”, and which was used fairly extensively for a while on Wikipedia.

W4G Rating Bar (https://mediawiki.org/wiki/Extension:W4G_Rating_Bar) ­ provides an input to let users rate pages, and then shows the results, on the pages themselves and elsewhere.

CommunityVoice (https://mediawiki.org/wiki/Extension:CommunityVoice) ­ lets users give star ratings to arbitrary things on a wiki page; any page can have any number of such inputs.

VoteNY (https://www.mediawiki.org/wiki/Extension:VoteNY) ­ lets users vote on pages, then shows the highest-rated pages elsewhere. This is part of the SocialProfile family of extensions; see here.

Semantic Rating (https://www.mediawiki.org/wiki/Extension:Semantic_Rating) ­ used in conjunction with Semantic MediaWiki (Chapter 16); lets users enter ratings within forms, and then allows for displaying individual and aggregated ratings, all using a five-star display.