Anyone Can Edit

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.

I absolutely love Vector. I think it’s a fantastic refresh of the classic Monobook skin and I wouldn’t mind seeing it as the default skin for MW one day. However, I think it was written very poorly.

The Mediawiki skin system sucks donkey balls. Once upon a time, we had a base skin class called Skin. New skins extended this class and customized the portions they need. Then along came Monobook and the absolute hell that is SkinTemplate. The skin system is now a hybrid: some older skins directly subclass Skin (which is technically correct) and anything more recent (Monobook, Modern, Vector) all subclass SkinTemplate. The problem with SkinTemplate is that it basically forked the skin system. We now have 2 ways to make skins–subclassing either Skin or SkinTemplate–neither of which are terribly intuitive for new users. When Modern was written, it basically made a copy of Monobook, changed a few things and called it a skin.

When the Usability Team set out to write a new skin this was the prime time to make this whole system make sense. Refactoring as much as possible out of the custom skins and unifying the UI across skins as much as possible would be awesome. Killing SkinTemplate with fire would be even better. Sadly, we got another skin built in the same crappy way using SkinTemplate. Even more work to whatever poor soul finally decides to tackle making a sane skin system.