Critical views of MediaWiki
From Wikinfo
- See main article: MediaWiki (Sympathetic Point of View)
There are many problems with MediaWiki, the wiki engine that became popular contemporarily with Wikipedia. Like other wiki engines, MediaWiki is a software package which one installs on a web server to create a wiki, but some of those lesser-known wiki engines are better, simpler, and less problematic than MediaWiki.
MediaWiki is a heavyweight; it requires not only the PHP scripting language but also the MySQL relational database software, plus a huge assortment of other external programs to enable all of the features. Even with those features enabled, MediaWiki still does not provide some of the basic traits of a typical wiki. Meanwhile, MediaWiki is so difficult to install and upgrade that many sites run old, vulnerable versions. Many features of MediaWiki are almost useless, and the possibly useful features are poorly documented.
MediaWiki evolves too rapidly for some wiki editors to track. It is true that wikis with MediaWiki installed and maintained carefully and properly can sometimes be great places to participate, but some wikis are using MediaWiki when they should be using something else.
Contents |
History of development
The development of MediaWiki was and is an unusual process. Know that MediaWiki was and is intended to be the wiki engine of Wikipedia. The Wikipedia community, with all their faults, has an almost-exclusive influence over MediaWiki. Even though Wikimedia, the organization that hosts Wikipedia, now uses MediaWiki in some other projects, MediaWiki continues to be primarily for Wikipedia.
Wikipedia originally used the UseModWiki engine, a simple Perl script that stored the wiki pages in text files. Some eager software developers decided that it would be better to store Wikipedia in a MySQL database, and created a new "Wikipedia Phase 2" engine using MySQL and the PHP script. Now OpenFacts - http://openfacts.berlios.de/ - is a rare example of a wiki that today uses Wikipedia Phase 2 software.
Later, the Wikipedians redesigned their software again, creating the "Wikipedia Phase 3" engine, now renamed to MediaWiki. MediaWiki gained features as it furthered the design of Wikipedia. From there MediaWiki spread. Wikimedia used MediaWiki to start other wikis. Others installed MediaWiki on their servers so that they could have wikis behaving like Wikipedia; SourceWatch (formerly Disinfopedia) and Wikia are examples of this. A fork of MediaWiki called GetWiki appeared on Wikinfo. The awful effect of all this is that every site using MediaWiki is designed like Wikipedia. News articles would herald not a new wiki, but a new site that was "Wikipedia-like".
Yet before the so-called current version of MediaWiki comes the old versions used at practically every MediaWiki site.
Few wikis run latest stable version
MediaWiki is a free software program conveyed through the GNU General Public License; the current version is 1.9.3, released 20 February 2007 (so http://www.mediawiki.org says). Easily enough, it comes as a PHP script called index.php, plus several include files; however it also has a large collection of auxiliary scripts for maintaining the database. Yet among the many MediaWiki installations in existence, it is difficult to find any running the current version.
The http://www.mediawiki.org site (and also Wikipedia and all other Wikimedia sites) run the latest development code. (To be correct, http://test.wikipedia.org/ runs the latest code "a few minutes before they appear on the rest of the Wikimedia wikis".) Wikimedia itself often refrains from using its own latest stable version. For example, MediaWiki 1.7.1 was the current version as of 8 July 2006, but Wikimedia never installed it upon their own wikis; they switched to the development code for 1.8 development code before their own 1.7.1 came into existence.
Some other sites also prefer to run the MediaWiki development versions that Wikimedia actually uses, rather than the so-called stable versions. For several months in 2006, Wikia, a wiki farm using MediaWiki, used a MediaWiki development version. Specifically, their running version of MediaWiki was 1.7alpha (r15298), which refers to development code when MediaWiki 1.6.x was current. Wikia later upgraded to 1.7.3, a version that Wikimedia never used. EditThis.info, another MediaWiki farm, does actually run a stable version of MediaWiki. But their running version has been the old 1.5.5 version throughout the latter half of 2006 and into 2007.
Nearly all MediaWiki installations run an older version of MediaWiki, not the latest stable version. This could be due to any number of reasons, from lack of technical interest or expertise on the part of wiki maintainers, to the feeling of no need to upgrade, to confusion over the changes in new MediaWiki versions. Another major obstacle is the frequent changes in the database format beneath MediaWiki. During an upgrade, server administrators may have to run one or more conversion scripts included with the new version of MediaWiki, with the risk that each script will damage the database of wiki pages instead of converting it.
For example, some wikis that run MediaWiki 1.7.1 (as of 4 March 2007) include WikiKnowledge, NYC EMC, MidnightWiki. Meanwhile, wikIran runs MediaWiki 1.8.3 while GameWikis runs MediaWiki 1.9.1.
MediaWiki breaks with wiki traditions
Even a MediaWiki 1.9.3 wiki lacks several features of a traditional wiki.
MeatballWiki, on their WikiPediaIsNotTypical page, had this to say about it (as of March 2007):
- "The typical wiki uses one of a number of widely-used wiki software packages, each of which is more or less intended to be general-purpose.... In contrast, the Wikipedia uses software developed from scratch specifically with Wikipedia in mind.... The software contains several unusual features: free links to the exclusion of CamelCase, multiple namespaces, a "watchlist" feature, stronger abilities to view pages edited by a specific user, and an SQL back end."
MediaWiki does have several unusual features, and also misses several common features. (The GetWiki engine that runs Wikinfo and GetMeta inherits some of these problems, but fortunately none of the many more recent quirks of MediaWiki.)
Clicking title to search
Consider one useful wiki tradition, that clicking the title of a wiki page perform a search of that wiki for the title. For example, try the SandBox page at Meatball Wiki; one can click the title of the page to search for other pages containing the text "SandBox". On a wiki where every WikiWord is a link, such search effectively finds all backlinks from that page.
To be fair, MediaWiki is not the only wiki engine to drop this feature. JSPWiki, TWiki and PBwiki all do not permit users to search by clicking on or near the title. One can use http://www.jspwiki.org/ or http://twiki.org/ or http://yummy.pbwiki.com as examples. (MediaWiki does have "what links here" and JSPWiki does have "referenced by" to search for backlinks.)
CamelCase or WikiWord links
Somewhat more importantly, MediaWiki has dropped another tradition that nearly all other wiki engines support: the CamelCase link.
When most wiki engines encounter a WikiWord in the wiki markup, they make a CamelCase link. Users from links simply by SmashingWordsTogether. This also makes it easier to tell names of wiki pages from names that do not refer to wiki pages. No configuration of MediaWiki supports this feature.
Though many wiki engines support both CamelCase links and free links, MediaWiki only free links. MediaWiki requires users to type [[two pairs of square brackets]] around text to make links; MediaWiki borrowed this syntax from UseModWiki.
It is now true that some sites hae wiki engines that support CamelCase links, but ask their users to avoid making them. For example, http://wiki.kde.org (which runs Tikiwiki) has a KDE Wiki Guide that requests users, "Name your page like e.g. KDE User Guide (please keep using this model of naming wiki pages how we decided in the pollexternal link) or Something Doc, etc." In Tikiwiki syntax, this entails the typing of ((KDE User Guide)) or ((Something Doc)), though Tikiwiki could have handled KdeUserGuide or SomethingDoc.
As, WikiMatrix's CamelCase page makes clear, CamelCase does not work in some languages. However, it remains a very useful tool when writing in the English language. The WikiWord link continues to be a feature that many users expect but that MediaWiki does not have.
So there are some wikis that run MediaWiki but do have pages named in the CamelCase style. For example, Wesnoth's MediaWiki has pages with titles like BasicStrategy, HomePage and WesvoidCampaign. Because MediaWiki does not support CamelCase links directly, it is a requirement that users write [[WesvoidCampaign]] instead of simply WesvoidCampaign to link to such pages.
Though it lacked the above features, MediaWiki has other features that are actually impediments.
Wasteful pages of talk
MediaWiki insists that every page is paired with a talk page.
This is implemented in terms of MediaWiki's namespace feature. A page in the main namespace [[X]] has a corresponding page in the talk namespace [[Talk:X]]. If there is a "Wikipedia" namespace, then a page [[Wikipedia:X]] has a corresponding page [[Wikipedia talk:X]]. (In a confusing manner, if there is no "Wikipedia" namespace, then MediaWiki pairs [[Wikipedia:X]] with [[Talk:Wikipedia:X]].) This is a really a requirement, so all new namespaces must be created in pairs.
In a few strange cases, MediaWiki is unable to pair a page. Such lone have strange names [[Talk:Talk:X]].
The talk pages serve to squash an old wiki tradition. With most other wiki engines, users will add comments to the bottom of a wiki page. This is TalkMode. The comments are part of the page, so wiki editors may easily remove or refactor them. Some wiki engines allow comments to be posted below a wiki page, to guard the comments against unwanted tampering.
Though Wikipedia insisted that comments would not appear too near encyclopedia articles, MediaWiki implemented talk pages. Every Wikipedia article has a link to the talk page, whether or not the page contains anything. Users are expected to put all comments on the talk page. This works well on pages that have many editors, such as many Wikipedia pages, but this works poorly on smaller wikis. On those wikis, many talk pages will either be empty, or contain only single comments or spam. Because the talk namespace hides the comments on separate pages, few readers see them. This diminishes the value of commenting.
Meanwhile, large wikis can use their talk pages to host endless debates about, for example, how many spaces to type after each period. Users tend to split long [[Talk:Something]] pages into subpages like [[Talk:Something/Archive 1]]. Now MediaWiki will tell readers that such a page is the talk page for [[Something/Archive 1]], so what should be on the [[Something/Archive 1]]? Later, if the wiki community decides to delete the [[Something]], they may orphan the [[Talk:Something]] page and its subpages.
MySQL is not so great
MediaWiki has an awkward requirement that all wiki pages must be stored in a MySQL relational database. If one does not have a MySQL database available, then one cannot install or run MediaWiki. There is no support, there has never been support, for storing the pages in flat computer files.
The developers intended the use of MySQL since the creation of Wikipedia Phase 2. They intended that MySQL would improve the performance of MediaWiki. However, this improvement has never occurred, and MediaWiki actually has several performance problems that MySQL does not resolve.
Take it from Patrick Michaud, the author of the PmWiki engine, that the use of a relational database does not benefit wiki. Patrick Michaud has made the case for flat text files in a page entitled FlatFileAdvantages. PmWiki always uses text files, never a database, to store the wiki pages.
There are two main reasons to use MySQL, or any sort of relational database:
- To speed and reduce the burden of queries such as searches, especially when the types of queries are not known in advance.
- For large wikis, to offload the data storage burden to one server, while running the web server and wiki engines on another server.
Neither of these reasons apply well to wiki. A wiki must spend most of its time doing boring, predictable tasks such as fetching pages, retrieving page history, or saving new revisions of pages. All of these operations can more easily be performed on text files in a simple filesystem, without the use of a relational database. An SQL relational database is more useful for unpredictable queries. If you do not know whether users will search for all items at the US store costing more than $10, or all items imported from Canada costing more than $10, or all items at the US store imported from Canada, or all items at the US store imported from Canada in December 2006 whose names start with "B", or so on, then you might store information about the items in a relational database. If you want to know how many wiki pages containing the words 'wiki farm', or how many wiki pages are three links away from this one, or how many users have edited pages about wiki policy, and the wiki is very large, then a relational database will help. However, the wiki will be too busy with other tasks to support much querying.
The second reason, to have the wiki engine and the data storage on different servers, causes MySQL and other relational databases to be attractive manners of storage. Programs like MediaWiki and phpBB use sockets to communicate with the SQL database server, and these sockets can easily be TCP sockets across different machines in a server farm. However, this sort of separation could more easily be achieved by using any sort of Network File System. A network filesystem will not perform searches or check passwords like an SQL server might, but other programs can perform that task, exactly as they would with a local filesystem.
There is abundant evidence that MySQL does not improve the performance of wiki. One might think that using MySQL to store wiki pages makes searches faster. But during the years 2004 and 2005, it was routine for Wikimedia to disable the search feature on Wikipedia and its other large MediaWikis. To anyone who tried to search a Wikimedia wiki, Wikimedia would divert them to Google. Thus, the use of MySQL instead of flat files did not solve the search problem.
The use of MySQL also does not solve statistical problems, such as finding the 100 longest pages. Large MediaWiki installations inevitably enable the "miser mode" that recomputes such statistics only once per day, instead of whenever a wiki editor requests them.
Today, Wikimedia actually copies its entire database from its server farms to a separate toolserver for running SQL queries. The toolserver is necessary because the usual SQL servers do not have time for queries.
Meanwhile Wikia, that wiki farm using MediaWiki, now runs an indexer on all of its wikis and offloads searches away from the SQL servers storing the wiki pages. Wikia might as well have stored the wiki pages in text files, even on a network filesystem, if MediaWiki had not required MySQL. For in this case the benefits of SQL are mostly neglected!
Several other wiki engines, such as UseModWiki and PmWiki, do not support the use of MySQL or any other relational database as the backend for storing the wiki pages.
Categories and templates
As new MediaWiki features appeared, the situation became worse and better. (GetWiki avoided most of this and has remained stable since 2004.) MediaWiki added a new wiki category feature encouraging a wiki to categorise all of its pages. However, instead of following a hierarchy, several wikis used MediaWiki categories like social bookmarking tags, hoping that some wiki pages would accidentally group together. The tactic really only works on very large and general wikis like Wikipedia. On other wikis, this tactic produced a mess of 1-page and 2-page categories.
Meanwhile, MediaWiki introduced template messages. Now pages, when transcluded into other pages, could take parameters. Template:Infobox webcomic at Comixpedia is a good and functional example of this. The bad thing is that MediaWiki had many bugs related to templates, including a whole set of bugs involving the combination of templates and categories. These bugs have now been fixed, or have they? So many wikis run older versions of MediaWiki with more bugs.
Example: RogueBasin has difficulties with MediaWiki
http://roguebasin.roguelikedevelopment.org is an example of a bad use of MediaWiki.
Counterexample: Wesnoth wiki
Somehow, http://wiki.wesnoth.org found that switching to MediaWiki was beneficial.
