MediaWiki 1.19 deployment to Wikimedia sites: Test it before it breaks

Translate This Post

The logo of MediaWiki (a yellow sunflower surrounded by two pairs of blue square brackets) with gradients symbolizing its coming to age for the next version
Wikimedia sites will gradually be upgraded to version 1.19 of MediaWiki over the second half of February 2012.

This article is available in other languages on mediawiki.org.


Wikimedia engineers are putting the final touches to the latest version of MediaWiki, the software that powers Wikipedia and its sister sites. This version, labeled “1.19wmf1”, will be deployed to Wikimedia sites in stages, starting next week.
We’ve recently set up a Beta cluster, replicating a selection of Wikimedia wikis, where Wikimedians have tested the new version and checked that it worked reasonably well with their local wiki’s specific customizations.
Things are looking good, and the current plan is to run the deployment in five stages between February 15th and March 1st, 2012. The schedule may change based on unexpected issues, so you should refer to the MediaWiki 1.19 roadmap for an up-to-date schedule of when your wiki will be affected.
Many new features and bug fixes brought by MediaWiki 1.19 are back-end, behind-the-scenes changes, for example infrastructure work to support our ongoing move to Swift as our media storage platform.
There are also more visible improvements, like better diff readability for colorblind people, and better support of the user’s gender and language in the interface. A list of all changes is available in the draft release notes.

Check JavaScript and Gadgets compatibility with ResourceLoader

A particular area of improvement in MediaWiki 1.19 relates to JavaScript. While most of the legacy site scripts, user scripts and gadgets will continue to work, it’s also possible that the new version be less forgiving of assumptions and errors in code. For example, faster load times may uncover errors in scripts that don’t explicitly declare the modules they’re using.
Furthermore, a new version of ResourceLoader will be deployed later this year, that will bring improvements specific to gadgets, but will require gadgets to be made compatible with ResourceLoader.
Gadgets maintainers are therefore strongly advised to start upgrading their scripts now, to avoid major disruption later. The migration guide to ResourceLoader is the main document for Gadget developers; a list of JavaScript deprecations and default modules are available as well.
You can also join the 2011 Resource Walker, an attempt to go through all Wikimedia wikis and update outdated JavaScript. An IRC workshop is planned to facilitate the process; more information will be posted later on this blog.

Moving towards transparent upgrades

As we move towards more frequent software upgrades, we expect them to be less and less painful — and ideally, at some point they’ll go so smoothly that users won’t even notice them, except for the new features that will appear. We’re not completely there yet, but we’ve made progress in the past year or so, and we’re committed to continue our efforts, both for the benefits of developers and users.
In the meantime, please bear with us if, despite our efforts, you encounter issues due to the upgrade; we’ll try and fix them as soon as we can. It’s not too late to visit the Beta cluster and report issues there or in our bug tracker. The more people test beforehand, the smoother the deployment should go.
Guillaume Paumier
Technical communications manager

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

4 Comments
Inline Feedbacks
View all comments

Good news for starting a new wiki-based website. I love it how your software becomes more and more robust each time.
Submitting bugs would be more helpful, when the developers would not reject them as already existing bugs. Most of the time the users can not describe the problem well enough, so that it looks similar to other bugs.
Thank you for great work !

If a bug is rejected as already existing (in Bugzilla this is “RESOLVED DUPLICATE” with the bug number given) then check to see if it is the same bug. If it is not the same bug, you can re-open your bug report and say *why* it is the not the same bug.
It is certainly better to have a few clearer bug reports (something this process will produce) rather than many vaguely similar bug reports.

Just out of curiosity, from line 105 of the release notes:
Added $wgSend404Code, true by default, which can be set to false to send a
200 status code instead of 404 for nonexistent articles.
What would be a reason to want nonexistent articles to return OK status?

Re #3: one reason to return a 200 OK for a missing article rather than 404 Not Found is because a large number of Microsoft IIS setups out there is misconfigured and will override any 404 response with a custom error page, even if the response body contains, say, an edit form.