The Signpost

Technology report

Looking ahead to MediaWiki 1.19 and related issues

MediaWiki 1.19 preview

MediaWiki 1.19 will implement improved timezone recognition

Developers working on MediaWiki 1.19, the latest version of the software on which Wikimedia wikis run, are now welcoming beta testers (as announced, for example, on Wikimedia Commons' village pump). According to the release's page on MediaWiki.org, it will feature improvements to the distribution of CSS styling, block log searching, timezone recognition and diff readability (as previously reported); and increased support for different relational database management systems and different languages and scripts. Over a hundred bugs are also expected to be fixed in the release (a reasonably comprehensive list of these is available).

The lengthened testing period (and more generally, the broadness with which testing is being carried out) is designed to head off the kind of implementation problems that have marked previous deployments. Work on reviewing the 1.19 code prior to deployment slowed this week, under the burden of SOPA blackout preparations. As a result, the January 31 deadline for code review will almost certainly be missed; at time of writing, 177 revisions are still in need of review compared to the target of just 44 (full chart).

The importance of 1.19 could well extend beyond its actual deployment; it is currently slated as the final SVN release before a faster, Git-based release cycle kicks in (details). As such, how well the existing process functions is likely to significantly influence the many choices that will be made during the migration to Git.

JavaScript problems ahead?

Another problematic issue of interest to wikitech-l regulars this week was referenced in a short exchange between staff developer Timo Tijhof (better known by his alias Krinkle) and bugmeister and general development process overseer Mark Hershberger. The issue centres on the tricky matter of the correct balance between backwards compatibility and modernisation in the realm of JavaScript loading.

Since the introduction of ResourceLoader in MediaWiki 1.17, core scripts and (some) gadgets are loaded as 'modules'. One of these modules is 'mw.util', on which many user scripts now rely for proper operation. The problem has arisen because, in the past, little effort was made to economise the loading of these modules, and they were assumed to be present when another script needed them (including Common.js). For the past 18 months, however, much more time has been devoted to streamlining the loading process, allowing for faster loading times and a reduced physical footprint for each page: a boon for those on slow Internet connections.

However, this improvement makes it necessary for scripts and script writers to declare which modules their script relies on (known as 'dependencies'). Officially, this has been mandatory since the introduction of ResourceLoader, but until now, these modules were already loaded by other core scripts, allowing scripts to run without errors.

Many scripts have been, or will need to be, updated to conform to the ResourceLoader specification, however. That is ultimately where the problem of backwards compatibility comes in: how to transition to the new standard while not breaking functionality of existing scripts, particularly on smaller wikis that could have lain untouched for years. "If we upgrade MediaWiki and we know that people are going to complain because a widespread dependency (like mw.util) disappeared, let's [avoid making that happen]" wrote Hershberger, "[Nobody wants a] horribly shocking experience after we upgrade the cluster". The best way to achieve that without largely nullifying the performance gains from modernisation is still being discussed (see this bug report).

In brief

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.


















Wikipedia:Wikipedia Signpost/2012-01-23/Technology_report