Wikipedia:Wikipedia Signpost/2011-10-10/Technology report

1.18 deployment and HTTPS switchover completed, but developer help now needed with new projects

1.18 deployed to remaining wikis

With the dust settled from the first two phases of the deployment of MediaWiki version 1.18, on October 4 the full rollout programme began. Since small but technically interesting wikis had been the focus of the first two phases, only 2% of traffic had been routed through MediaWiki 1.18; now, all visitors and editors will be able to take advantage of its new features, which include support for gender-specific user pages and better directionality support for

, progress with the final phase was slightly slower than anticipated but still good, with the French, Polish and English Wikipedias, along with Wikimedia Commons, having their version of MediaWiki updated within the first four hour window. Other wikis were then transferred during secondary windows on October 5 and 6. The deployment did not go perfectly, however, and a number of bugs have since been discovered with 1.18; as of time of writing, approximately 40 open ones are currently being tracked under the auspices of bugmeister Mark Hershberger, although few are serious. The list of bugs reported but not yet fixed includes problems with the watchlist API (bug #31526), the localisation update system (bug #31559) and the display of <math>...</math> (bug #31442). Responding to the relatively high volume of bugs found despite a recent emphasis on improving Wikimedia and MediaWiki's pre-release test infrastructure, Hershberger appealed for help in writing unit and/or parser tests for key bug fixes to ensure that regressions are spotted more quickly in the future. If this is the case when 1.19 nears deployment (currently scheduled for late this year), the whole process would be likely to pass off "a *lot* smoother", wrote Hershberger (wikitech-l mailing list).

Improved https support comes to Wikimedia wikis

Also announced this week was the https switchover. Writing for the Wikimedia Foundation blog, operations engineer Ryan Lane said that the secure.wikimedia.org domain had been officially deprecated. Lane advised security-conscious visitors to simply change http to https in their URL instead to take advantage of new functionality which has taken months of planning to achieve (including the introduction of protocol-relative URLs). In addition to a noticeable speed improvement over its secure.wikimedia.org forerunner, Lane was clear on the benefits of the switchover to full https functionality:

“

[Unlike with secure.wikimedia.org,] the URLs are exactly the same, just the protocol is different. The SSL servers only do SSL termination, and they do it before our caching layers. This means that this is a transparent addition to our architecture. When we scale other pieces of our architecture, this will scale with it [unlike secure.wikimedia.org] We can remove our CSS, JavaScript, and web server hacks. This simplifies everything, and makes it far less likely we'll have mixed-content issues.

”

The deployment of new https functionality was commended by many commentators; one wrote that "the lack of proper HTTPS" support had in his eyes been a long-standing issue with the site. At time of writing, support for secure browsing on the mobile site has not yet been enabled (bug #31333) – there are no plans to enable mobile support until the mobile and non-mobile sites are fully merged – but the core support for non-mobile devices outlined by Lane in his blogpost at least appears to be working correctly. HTTPS Everywhere, a popular browser add-on designed to make it easier to use the secure version of a website where it exists, is in the process of being updated to take advantage of the new format (wikitech-l mailing list).

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.

• Quick fix turnaround for serious bug: A bug in the JavaScript component of Wikimedia wikis that caused the browser windows of Internet Explorer 8 users to crash has now been fixed. The bug (#31424) was fixed only a day after it was filed, tracked down to a fault in the jQuery library version that MediaWiki 1.18 came packaged with (wikitech-l mailing list). The version of jQuery packaged with MediaWiki has since been upgraded to a version that does not cause the problem and Wikimedia wikis have been updated to reflect the change. In unrelated news, WMF Internalisation team member Gerard Meijssen blogged about bug #31310 as a paradigm for good volunteer involvement in making sure bugs are fixed quickly (it has since been re-opened pending further investigation).
• Discussion over conversion to Git continues: The finer details of a plan floated late last month to convert the MediaWiki repository to Git began this week on the wikitech-l mailing list. Discussion so far has focussed on the most widely acknowledged point of contention, whether MediaWiki should remain as one repository or spin-off extensions and/or localisation files into their own repositories.
• Wikimedia Blog mobile friendly: A special mobile edition of the combined Wikimedia blog was released this week, according to an announcement on the blog itself. Previously, mobile devices had been forced to display the full fixed-width layout that had been designed solely with larger screens in mind.
• $3.6 million grant announced: As reported in more detail in this week's "News and Notes", the Stanton Foundation have announced that they have awarded Wikimedia a $3.6 million grant to support technical projects aimed at making its wikis more newcomer friendly, including work on enabling editing from the new mobile site and the long-awaited visual editor project.
• Bot tasks open: Bot requests for approval are currently open on the English Wikipedia for helping automated Mediation Cabal pages and mass updating instances of a biological infobox. In addition, a BRFA focussed on article creation by Rich Farmbrough is also open.