Anyone Can Edit

It’s one of those wonderful times of the year, when we get to branch MediaWiki for a stable release. That’s right, MediaWiki v1.16 has been branched and a release candidate is underway. Those of you following MediaWiki–either as a Wikimedian or for your outside uses–know that 1.16 has been a long time coming. Code reviewing has finally caught up to trunk and it’s high time a release is put forth.

A lot has changed in 1.16 (for the brave, the full RELEASE-NOTES), and I’d like to hit on some of the major things here that I think need mention:

• The Metadata editor ($wgUseMetadataEdit) has been split into a separate extension, MetadataEdit
• Introduced CDB interface for high-performance constant data
• Default output format is now HTML5 instead of XHTML 1.0 Transitional (see $wgHtml5)
• Maintenance scripts got a lot of cleanup and reorganization, AdminSettings.php no longer required
• New hooks
• Major improvements in SQLite support
• Test suite is now at least organized (will see more coming here in 1.17)
• Many many other bug fixes and new features

Hopefully we’ll see a general update to the Wikimedia cluster coming in the very near future, meaning that non-critical bugfixes that have been “Fixed in SVN” will finally see production deployment. The first 1.16 release candidate will be coming soon as well, which I encourage those of you using MediaWiki to download and test it out for us. See what works, what needs tweaking and what’s downright broken. It’s a big release, so we’d like to get as much feedback as humanly possible.

Remember that all bugs goto Bugzilla (recently upgraded and restyled), and more information is always better than less.

Unit testing sucks. Tests are boring to write, nobody wants to run them, and thus they are subject to bitrot. For years, the only (actively) maintained tests were the parserTests to help handle regressions in MediaWiki’s wikitext parser. There were some PHPUnit-based ones in /tests and some custom TAP-based ones in /t. Neither worked perfectly, and neither is complete by any stretch of the word.

The past couple of days, things have at least improved. We’ve nuked /t entirely, meaning unit tests are going to be PHPUnit-based from here on out. All useful tests in /t were ported over first. Also, Mark has written a wrapper for the parser tests allowing them to be invoked as a normal part of the unit testing routine (this needs a rewrite to put the code in native PHPUnit format, rather than the hacky method we’re using now). While working on this, a couple of things have become apparent:

1. Globals suck. Period. Trying to set up an instance of MediaWiki–which relies wayyyy too heavily on globals–in a non-global context (which PHPUnit does not run in) is a pain. I plan to be much more agressive on globals post-branching.
2. We need more unit tests. Code coverage is far from complete, but at least by unifying the tests we can try to encourage people to write more tests.
3. Need to work with Brion to redo the magic upload-test-results-to-CR bridge. PHPUnit can output test results in a variety of formats (TAP, XML…), and CodeReview should use this, rather than reinventing the wheel ourselves.

Finally, all the tests have been moved from /tests to /maintenance/tests, removing yet another top-level directory in the install. Oh yeah, code review is pretty much caught up too, which is a Good Thing.

I swear I’m alive! I just kind of disappeared for a bit.

School got really busy, and then I ran off to Paris for the Multimedia Usability Project Meeting. It was massively productive, and I got to meet a lot of really cool people I’ve known for a long time online but never met in person. Also, major thanks to Delphine for putting the whole thing together and doing a generally fantastic job. A lot of really good work was accomplished while we were there. We spec’d out a new upload form, we discussed staging areas for new uploads while licensing stuff gets sorted out, the GLAM folks talked about their interests. We had a very good group dynamic of developers and non-developers, and I think it worked out very well in the end. We talked about getting similar small-ish focus groups together in the future; we seem to get a lot done. I’m not sure how these public links work, but here’s my pictures from Paris (if you’re my friend already, they should be viewable from my profile).

Flew back to Richmond, massively jet lagged. Then I got sick. Like, really sick. As in, I ended up in the hospital for several days kind of sick. In the end, they determined I had viral encephalitis caused by the herpes virus (read the scary article). They don’t know how I got it, but the best we can guess is that my immune system was shot from being low on sleep, stressed out, etc. And since the herpes virus is in a huge percentage of the population anyway–myself included–it took advantage of my poor brain. But I’m fine now, and just trying to catch up on life.

Maybe over winter break I can finally do something with MediaWiki again. Maybe we’ll actually get 1.16 soon too ;-)

Wikitext is a monstrous and ferocious beast. Born from a small set of markup choices for text formatting, it has since grown to a plethora of markup and functions. It’s gotten to the point where people are afraid to edit, due to the nearly insurmountable hurdle of learning the syntax.

The problem with wikitext isn’t in its design itself, it comes when people try to make wikitext do things it was never intended to do. Years ago, people realized that they could make a conditional template. The English Wikipedia produced a template called {{qif}} that quickly became used across the entire wiki. This was terribly inefficient, so ParserFunctions was born to solve this problem, and parser functions in general were born.

At some point, somebody wrote an extension to handle string manipulation called StringFunctions. Ever since then, enwiki has been practically begging to get it enabled (see bug 6455). This request has been repeatedly denied by the WMF sysadmins, in an effort to keep wikitext from becoming even more insane. Similar to {{qif}}, a series of workarounds have been written.

In our future ideal universe, we’d like to have some sort of meta programming language for templates. Various ideas have been tossed around, including a subset of PHP, Javascript or Lua. Any of these solutions each have their own set of benefits and drawbacks, and none of them are anywhere close to being enabled. And so the debate continues, often, as to what we should do with wikitext.

I remain convinced that wikitext itself is not inherently bad, and does not need fixing. The basic formatting markup and template inclusion is not horrible. It’s when people try to butcher wikitext to make it do things it was never designed to do that we get nasty results. Adding ParserFunctions didn’t ruin wikitext, ParserFunctions was designed so Wikipedia wouldn’t kill itself trying to implement their own {{#if}} function. I would argue that the English Wikipedia’s desire for programmatic templates is what made the language is what made this mess.