This week saw a number of developments regarding the MediaWiki software on which Wikimedia Foundation wikis run. The first, on the 4 May, was the announcement of a security update to MediaWiki 1.16, the version currently considered stable enough for all major external wikis to use (wikitech-l mailing list). Version 1.16.5 closed another security loophole related to those closed in 1.16.3 and 1.16.4 (see previous Signpost coverage) and additionally fixed a flaw in MediaWiki's implementation of $wgBlockDisablesLogin that allowed users to mimic unblocked users' cookies in order to gain additional permissions (no Wikimedia wikis were affected).
| “ | Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. | ” |
| — Developer Tim Starling on 1.17b1 (wikitech-l) | ||
Two substantive announcements were also made on 5 May. The first, of interest almost exclusively to users operating their own external wikis, was the release of a beta version of MediaWiki 1.17, the version already running on WMF sites (wikitech-l). The second, perhaps of more interest to Wikimedians, was the branching of MediaWiki version 1.18 (also wikitech-l). Although some changes are deployed out of process to Wikimedia sites, new releases such as 1.18 contain many smaller improvements of interest to editors and visitors alike. With 1.17 already live, branching 1.18 represents a significant step towards the deployment of another batch of improvements, already slated to include 179 bug fixes and feature requests, plus localisation updates (provisional release notes). 1.18 will now be left to "bake": no new features will be added to it as the release is purged of bugs, before going live to Wikimedia wikis ahead of a release to external sites. Commenting on the branch, former CTO Brion Vibber's post to wikitech-l consisted solely of the word "Woohooooooo!"; meanwhile, however, debates will no doubt be ongoing about the future shape of the MediaWiki release schedule.
After a period of being one option among many for uploading files to Wikimedia Commons, the new UploadWizard is to become the default on or around 9 May, it was announced this week (Wikimedia Commons). Local communities will then be able to adopt it as their own default method of allowing uploads.
The wizard, which has been in development for a number of months, boasts a number of improvements over the existing upload form, per Erik Möller:
| “ |
|
” |
A number of bugs linger, however, and these will need to be dealt with before the UploadWizard can enjoy widespread success. For example, uploads longer than 25 minutes still fail; thumbnails for some file formats (video and audio, for instance) are not shown during the upload process; right-to-left support is far from perfect and consistent; and there are a number of other known cases where uploads will stall and the user has no option to fix the problem. The relatively low interface translation rate (as of time of writing, it has been translated fully into only 14 languages) may also be a worry for a Foundation committed to total internationalisation. There are also worries that by making it easier to upload and removing many of the "traps" of the old upload form, a higher percentage of copyright violations may go undetected. Despite these concerns, the response to the new wizard has been largely positive.
Next week will see the Berlin Hackathon (13-15 May). The annual event, which began in 2009, will be focussed this year on "more hacking and less talking", say organisers. Volunteer developers and Wikimedia professionals alike will come together over a number of "core" projects (excerpted from MediaWiki.org):
Other projects are also likely to come up during the Hackathon, including the new Narayam extension and other work done recently regarding improving the user experience of those who write in non-Latin alphabets. Historically, the meetup has provided a focal point that invigorates projects, rather than an inclusive event where projects are begun, worked on and finished. The Signpost hopes to report the success of the 2011 event in future issues.
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.
{{#time:Y|1945}} now works properly. Other problems with the parser function remain unfixed, however, since they have their roots in the PHP programming language itself.
Discuss this story
- I am quite unsure how a blog post from Gerard Meijssen constitutes news in the brief. Is he not but an ordinary Wikipedian? AGK [•] 11:15, 10 May 2011 (UTC)[reply]
- News in brief includes interesting blog posts, and has done for as long as I care to remember (regarddless of whether or not their content constitutes "news"). Gerard is a prolific blogger when it comes to Tech issues, far exceeding any other sources in terms of quantity (official or unofficial). Though he is "an ordinary Wikipedian", he has strong links with other communities such as TranslateWiki, and consequently gives airtime to a number of issues not included in other sources the author of the Tech report (I) routinely look use for the Report. For these reasons, his blog posts end up having a regular, but I don't think particularly undeserving, place in the "In brief" section. I would happily give similar space to picking out interesting (Tech-related) blog posts from any other "ordinary Wikipedians", and it's only because they don't write them that they don't compete for space with Gerard. Regards, - Jarry1250 [Weasel? Discuss.] 14:17, 10 May 2011 (UTC)[reply]
"A number of bugs linger"—so the WMF is like Microsoft, eh? Push out the cool stuff first and fix the bugs later. /ƒETCHCOMMS/ 18:09, 10 May 2011 (UTC)[reply]