MediaWiki update coming on Wikipedia…

Update: It’s live! We did encounter one more fun bug that affected some bot edits and the ‘undo’ function, but this is now fixed too.

I’ve updated to MediaWiki r44462.. after a couple more hours testing, I’ll push it live to all wikis.

List of items changed since last update from our release notes:

New features

  • (bug 44) Image namespace and accompanying talk namespace renamed to File. For backward compatibility purposes, Image still works. External tools may need to be updated.
  • The constants NS_FILE and NS_FILE_TALK can now be used instead of NS_IMAGE and NS_IMAGE_TALK. The old constants are retained as aliases for compatibility, and should still be used in code meant to be compatible with v1.13 or older.
  • MediaWiki can be forced to use private IPs forwarded by a proxy server by using $wgUsePrivateIPs.
  • Dropped old Paser_OldPP class. Only new parser with preprocessor is used.
  • Moved password reset form from Special:Preferences to Special:ResetPass
  • Added Special:ChangePassword as a special page alias for Special:ResetPass
  • Added complimentary function for addHandler() called removeHandler() for removing events
  • Improved security of file uploads for IE clients, using a reverse-engineered algorithm very similar to IE’s content detection algorithm.

Bug fixes in 1.14

  • (bug 11728) Unify layout of enhanced watchlist/recent changes
  • (bug 8702) Properly update stats when running nukePage maintenance script
  • (bug 7726) Searches for words less than 4 characters now work without requiring customization of MySQL server settings
  • Honour unchecked “Leave a redirect behind” for moved subpages
  • (bug 16440) Broken 0-byte math renderings are now deleted and re-rendered when page is re-parsed.
  • (bug 6100) Unicode BiDi embedding/override characters (U+202A – U+202E) are now automatically removed from titles; these characters can accidentally end up in copy-and-pasted titles, and, by overriding normal bidirectional text handling, can lead to annoying behavior such as text rendering backwards
  • Fixed minor bug where the memcached value for how many accounts an IP had created that day would be increased even if $wgAccountCreationThrottle was hit. This meant if an IP hit the throttle and then the throttle was raised later that day, the IP still couldn’t create another account, because it had marked them as having created another account, when their last account creation had actually failed.
  • (bug 12647) Allow autogenerated edit summary messages to be blanked with ‘-‘
  • (bug 16026) ‘Revision-info’ and ‘revision-info-current’ both accept wiki markup now.
  • (bug 16529) Fix for search suggestions with some third-party JS libraries
  • (bug 13342) importScript() generates more consistent URI encoding
  • (bug 16577) When a blocked user tries to rollback a page, the block message is now only displayed once
  • (bug 14268) SVG image sizes now extracted with proper XML parser
  • (bug 14365) RepoGroup::findFiles() no longer crashes if passed an invalid title via the API
  • (bug 4253, bug 16586) Revision ID is now given instead of title in URLs for new pages in the recent changes IRC feed
  • Fix regression caused by r43047 — options arrays in show/hide links broken by being merged in the wrong order when moved from wfArrayMerge() to “+” operator.

API changes in 1.14

  • (bug 12760) meta=userinfo&uiprop=ratelimits doesn’t list group-specific rate limits
  • (bug 16398) meta=userinfo&uiprop=rights lists some rights twice in some cases
  • (bug 16408) Added rvgeneratexml to prop=revisions
  • (bug 16421) Made list=logevents’s leuser accept user names with underscores instead of spaces
  • (bug 16516) Made rvsection=T-2 work
  • (bug 16526) Added usprop=emailable to list=users
  • (bug 16548) list=search threw errors with an invalid error code
  • (bug 16515) Added pst and onlypst parameters to action=parse
  • (bug 16541) Added block expiry timestamp to list=logevents output

Note the ‘File:’ namespace is ready to deploy but won’t be live there yet since test currently still uses the older message files. It should go live after full deployment. Update: fixed that bug, now it uses the new namespace and all new/update messages are live on test. :D

One thought on “MediaWiki update coming on Wikipedia…”

  1. At the risk of tooting my own horn, I’d like to add to the list of improvements above :) There was no bug for it (I probably should add it to RELEASE-NOTES anyway), but there was a lot of work done on the ForeignApiRepo code between last scap and this one. Granted, this doesn’t directly apply to WMF wikis, but hey, it’s a good thing, right?

    Brion: speaking of, we’ve got a little discussion going over here on a post a made. Trying to think up ways to make the code more robust and fault-tolerant. Input, as always, is more than welcome.

Comments are closed.