Jeroens blog

As it’s been 2 months since my last blog post, I figured it was time for another one. Quite a few things I could write about (SMWCon, my new awesome laptop, Stanfords AI and ML classes, me moving to Berlin, …), but I decided to give some introduction to my most recent MediaWiki extension: Contest.

Contest extension that allows users to participate in admin defined contest challenges. Via a judging interface, judges can discuss and vote on submissions. I created it for the Wikimedia October coding challenge, so it got a nice amount of review, uncovering some minor misconceptions I had about some core MW code, and it got deployed on MediaWiki.org. The coding challenge is quite awesome, but I won’t discuss it any further here, so check out the linked blog post if you’re curious/interested.

Feature overview:

• Admin interface for managing contests and their challenges.
• Landing and signup pages for each contest.
• Personal contest list and submission interface for each user.
• Summary pages per contest listing contestants, which can be filtered and sorted.
• Judging interface that allows for rating and commenting on each participant.
• All contests, challenges, contestants, comments and votes can be queried and exported via the API.
• Signup and reminder emails.

Requirements

• MediaWiki 1.18 or above – yeah! my first awesome MediaWiki 1.18 or later extension
• PHP 5.2 or above
• MySQL

Some screenshots

Contest welcome interface

Contest submission and management interface for a single user

Contest administration and judging interface listing all contests

Contest administration and judging interface for a single contest

Contest editing interface

Judging interface for a single submission

Some background

When starting with this extension, it was clear pretty quickly that it could really use the awesome DBObject class I’ve been incrementally creating over my last few extensions and mostly finished in Survey. This class is a wrapper for objects of a certain type, which is equivalent to a row in some db table. Even though it’s in essence very simple – it just has a field that is an associative array with field => value – it’s also very powerful and flexible. When I started with this, I had no idea it would turn out to be so neat. The bad news was that I could not use PHP 5.3 or later for Contest, while the DBObject class uses late static binding, which was introduces in PHP 5.3. I came up with a simple hack: all static methods in the base class have been made-non static, but are marked as “should be static”. Then, every deriving class has a public static function s(), which returns a (cached) instance of the class. So then for every “static” method you need to call, instead of ClassName::methodName(), you do ClassName::s()->methodName(). If you know this, and do not misuse the non-static-but-should-be-static methods in the base class, it retains all it’s niceness, at the cost of something that’s pretty much a tiny bit of syntactic sugar. And it’s quite obvious how easy it will be to replace this with actual LSB usage once this becomes possible

• Survey DBObject class – deriving class
• Contest DBObject class – deriving class

Download

• Release tarballs
• SVN tags
• SVN trunk

What’s next?

There are various small additions that could be made, but one things really stands out: contest configuration with version history. Right now, you can create contests and challenges, modify them and delete them. But once you make a change, the previous version is lost. You cannot revert. You cannot compare. You can’t even see who made the change or when. Implementing such a thing is not trivial, especially if you want to have a generic system that can be used by any extension that wants to store data and have version history for it. And if you think about it, quite a few extensions could use this. Let’s have a look at my extensions, latest first, and see if they can use it:

• Contest – well yeah, obviously
• Survey – yes, for the surveys, their configuration, and their questions
• Semantic Watchlist – yeah, for the watchlist groups
• IncludeWP – no
• SubPageList – no
• Live Translate – yeah, for the translation memory admin
• Push – no, although it could, if it had an admin interface for the push targets
• Validator – no
• Maps and SM – yeah, for the map layer definitions currently done as key=value pairs, one per line, in the Layer namespace

That’s 6 out of 10 just for the extensions I wrote. What it comes down to is that pretty much any extension that has some sort of settings interface that is not user-specific, could use this. And maybe even the user specific ones, which would obviously include the user preferences in MediaWiki core. So why not store this data in wiki pages, such as done by Maps for layers? You could even store it as JSON or serialized PHP objects if you need more complexity… The things with this is that it only works for simple use cases (such as the layers in Maps), and even then is limited. You cannot query over the data as you do not have it in relational form. And you cannot have fine grained access and write rights control over the data, which in a lot of cases is quite important. So a generic solution here would be an awesome addition to MediaWiki if you ask me.

More info on Contest can be found on it’s documentation page.