MediaWiki reviews - MediaWiki

This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date.

It rocks. I already had mysql installed, and installing MediaWiki was like 4 very trivial steps. The one configuration change I wanted to make was on the FAQ, and after that I was all set. --Fcrick

I'm a MediaWiki developer and one of the founders of Wikitravel. We've been using MediaWiki for about a year and a half as of this writing.

MediaWiki is a great piece of software, but difficult. Development is principally aimed at Wikimedia servers, which is a pretty high-end configuration (multiple Web servers, multiple roll-over databases, array of reverse cache squid servers, lots of extra PHP caching engines). Since Wikitravel is hosted on an off-the-shelf Web service provider (I wouldn't have it any other way), we don't have access to these luxuries. So, our performance is kinda poor.

Developers also throw in features which are primarily for Wikimedia projects that may or may not be useful for other projects, without adding configuration variables to enable/disable those features. A lot of the work I do as a developer is figuring out how to turn off features that aren't useful for our project.

There's not a lot of concentration on making the software customizable or skinnable. Third-party extensions are hard to write and interfaces are pretty much undocumented.

The code base is really bloated and monolithic. There are tons of dummy modules and functions built in for compatibility with code that no longer exists. Logging is practically non-existent, unless you're willing to turn on "debug logging", which vomits out everything.

Within Wikimedia, system administration and programming are completely intertwined. If you want to talk about some class in some module in MediaWiki, be prepared to listen to lots of hard-disk optimization talk on the mailing lists and IRC channels. Also, there's practically no collaborative design process -- developers with CVS access stick in their pet projects and expect others to deal with the consequences.

Finally, there's hostility from Wikimedia developers and users. There's not a lot, and people are usually pretty great, but every once in a while people tell you to shut up if you don't like their software. There's also not a lot of openness to criticism, and people get pretty defensive. It's understandable: Wikimedia is a great project that commands a lot of loyalty. But still.

Bottom line? For admins outside Wikimedia, unless you're happy with MediaWiki as it is straight out of the box, I'd recommend against using this software. --Evan 19:39, 15 Nov 2004 (UTC)

So, I've been told that this review was too negative. I'd like to balance it with some addenda, at the risk of being longwinded.

First, I greatly admire the Wikimedia developers and sysadmin team. They deal with immense amounts of data and interactions every day; once they've got one level of complexity kinda under control, the whole thing goes to another order of magnitude. Somehow they manage to keep the huge number of Wikimedia sites running and add useful features and enhancements on top of that. Their brainpower and persistence make one of the miracles of the 21st century happen, and they deserve kudos.

Second, I'd like to qualify a couple of things mentioned above.

Developers also throw in features ... without adding configuration variables to enable/disable those features. I should note that this is the exception and not the rule, and that it's frowned upon in the development group. I can only come up with a few examples that exist in released versions of MediaWiki, and they've been fixed since.
Debug logging doesn't "vomit"; it just prints a lot of data that can be hard to interpret. Sorry for the provocative language.
Within Wikimedia, system administration and programming are completely intertwined. This situation has changed since I made this review. Wikimedia systems administration has moved out of the #mediawiki IRC channel, and that channel is now used mostly for development discussions and peer support. A similar change has happened with the mediawiki-l mailing list, which has become more of a peer-support list, but it's not as pronounced as the IRC change. The wikitech-l mailing list remains the main development list and also the main sysadmin list.
Also, there's practically no collaborative design process [..]. There is, in fact, a lot of discussion on IRC about design questions, and the senior developers are very helpful in guiding newer volunteers in their efforts.

Finally, I note that there's continuing tension around the use of MediaWiki by non-Wikimedia organizations and individuals. I think there are few people who'd disagree that the smooth and efficient running of the Wikimedia wikis is priority 1 for MediaWiki developers (myself included!). Whether it's usefulness for third-party wikis should be priority 2, priority 2000, or priority ∞ is still, as far as I know, formally undefined. --Evan 00:07, 31 May 2005 (UTC)[reply]

As a barely knowledgable MediaWiki user, the scripts are akin to being handed a running internal combustion widget: it's powerful, it's doing something, but you're not entirely sure what. And it just might hurt if you try to do something with it.

The documentation is poor to non-existent. The support, via the mail list, has always be quick and helpful. But there's a high noise-to-information ratio. The online support varies: most days it's fabulous - some days it sucks. (Today has been one of the latter, but I'm trying to keep it in perspective.)

Some basic documentation issues which come up repeatedly (and which would save a lot of time and effort by developers if they were in an easy-to-find FAQ or how-to-guide) include:

how to customize, especially the logo
how to upgrade (easy and long forms, for the current versions)
how to get the math/LaTeX system working
how to extend the magic words

The fact is, MediaWiki is a purpose-built software, and you aren't their purpose. On the support side of things, everyone is scrambling too hard to provide much support infrastructure. That isn't their purpose either. (IMO this is actually costing more developer time than building the appropriate infrastructure.) If you think you might need help setting up or maintaining a mediawiki site, well, that isn't the purpose of MediaWiki.

It's a good software - power hungry but able to scale - but it is not designed for small setups and there is poor support for amateurs. Accept it as is, or be the change you want to see. - Wikipedia:User:Amgine

I've helped bring wiki.castlecops.com online but still have lots of questions as to how to run a wiki fairly. Also I have technical questions that I haven't found good answers to. My question is whether there is any wiki user/admin/developer forum which is used to share such knowledge? If not, would anyone be interested in having one set up at castlecops.com? --Ikester 06:19, 14 May 2005 (UTC)[reply]

There is an IRC channel at #mediawiki on freenode and a mailing list at mediawiki-l.

Ridiculously easy to install and use. Very heavyweight, even on a single box with no load — it's as strong as a tank and as big as a Winnebago but has the handling and gas mileage of both combined. But you and your users will cope very nicely with it - David Gerard 09:42, 29 September 2005 (UTC)[reply]

In order to work on extensions, I installed XAMPPLite on Windows XP, and MediaWiki installation on that was straightforward. I agree logging and debug output is poorly supported (or poorly documented). What developer documentation I've found is good, but as with most software projects, the internals documentation only scratches the surface. -- skierpage 00:21, 17 November 2006 (UTC)[reply]