The Jackal Rants

Just thought I’d take a minute or two to showcase Mayflower, an excellent search engine specifically for the Wikimedia Commons, developed on the toolserver by Tangotango.

I don’t think I can praise this enough, to be honest. The interface is clean and professional, the engine itself is quite fast, and effective, and the whole experience left me quite satisfied as a user. This is a fantastic piece of work, and I wholeheartedly congratulate the developer for putting in some obvious hard work.

This is exactly what the toolserver was for, and I’m thoroughly pleased that our community is producing such innovations.

Just to follow up from the teaser screenshot I posted a short time ago, the forthcoming Screenshot extension is now demoing at http://wiki.anubite.co.uk/view/Slideshow.

It requires JavaScript, but will now show a decent fallback message if the client doesn’t support this, and messages (including button labels) can now be localised as normal.

Well, well, well, Wikimedia have new general counsel, in the form of Mike Godwin. Allow me to extend the warm welcome Mike’s getting, and to throw in the obligatory pun about Wikimedia wanting to invoke Godwin’s law more often from now on.

Working on a couple things at the moment; a new reporting mechanism, and some changes to the log formatting code.

Reports

The reporting mechanism will replace the old QueryPage system with a new one based around an abstract Report class, which is then extended to provide concrete functionality. As before, the actual running of the report is done by the superclass, and as before, reports can be cached. However, we’ll be storing sufficient data in the cache to allow filtering by namespace, and excluding redirects, where appropriate.

The report cache script also caches a different set of results for each namespace, so that there’s cached results for all namespaces. What this means is that, for something like Special:WantedPages, we’ll have separate sets for the main namespace, template namespace, etc. so that namespace filtering is still coherent when the cache is in use, as it will be on Wikimedia wikis. Of course, namespace filtering means that some reports have been merged together (Special:UncategorizedPages, Special:UncategorizedImages etc.)

I’ve also found a couple of opportunities to add possibile performance boosts; better indexes and the use of specific thresholds in “longest pages” and “shortest pages”, and something similar in “ancient pages”, which should speed these three up.

Reports are distinguished from other special pages in Special:SpecialPages, and extensions can add their own reports, too, which drop in and work with the report cache right off the bat. I’ve also tweaked the header text and done a lot of UI improvement.

There’s still quite a bit to do at the moment; some final reports need to be ported, and I need to finish rewriting Special:NewPages to be a proper SpecialPage – it was subclassing QueryPage, but there’s absolutely no need for this, since the table it uses – recentchanges – is cached to hell and back. I might end up merging some of the functionality of the NewestPages extension into Special:NewPages, since I’ve had feedback that the extension is better from a user point of view.

Log formatting

The changes to log formatting will mean that we have a clear and consistent single call to format an individual log item from anywhere. Coupled with the storage of some additional data in the recentchanges table, this means that we can go nuts, and have fully internationalised formatted log lines showing up in change lists, too – right now, it’s generated on save (in the content language) and then saved into the recentchanges table.

This allows me to add some much-needed extras and alter some of the log format entries about. For example, when the target is, in fact, a user, then the standard user links can be added. Extensions can either provide a method to do partial formatting, or take over the whole of the formatting process for their log items, which allows maximum flexibility.

This is coming along very successfully, and should also be done soon.

We had a visitor to #mediawiki yesterday, who was trying to get FCKeditor working with MediaWiki 1.9.3, and was at his wits’ end to the point where he was offering monetary rewards to anyone who could help him.

In my usual folly, I made him an interesting offer:

<robchurch> I tell you what, if I can get it working, from scratch, with MediaWiki 1.9.x, within half an hour, I'll tell you exactly how to do it, for nothing.

Well once I’d downloaded the editor and checked out 1.9.3 from a tag, and read the pertinent documentation on working with FCKeditor, I like to think it didn’t take me long to get it done…under 30 minutes, in fact.

My second mistake, of course, will have been making it available to everyone else, too. Should work with any version after 1.9.3, although there is some patching of MediaWiki involved (one line in the autoloader, and a couple of lines in the edit form code), and you have to enable raw HTML (but don’t panic, FCKeditor seems to be protecting against malicious-looking HTML), but someone else ought to find this useful.

• How it’s done
• Screenshot of the result

Update: I’ve updated the patch to fix some bugs and incorrect assumptions, noted on the discussion page. I should also point out that it’s not FCKeditor protecting against the malicious HTML, but MediaWiki’s own Sanitizer class, which has been tweaked in the new patch to allow some FCKeditor-generated HTML elements through to allow the nifty table generator, etc. to work.

I’m on a break from development work for the foreseeable future; a few weeks off (minimum) ought to allow me to sort out various pressing issues and calm down again. There’s a lot of flak associated with being a developer, which isn’t helped when one has an aggressive personality.

The big one-oh; MediaWiki 1.10.0 is out, bringing with it the newest stable release branch of MediaWiki. As usual, I recommend that all wiki operators begin plans for upgrading.

If you’re running MediaWiki 1.7.x or above, then you’re already configured to use PHP 5, and the regular upgrade instructions will work a treat. If running MediaWiki 1.6.x, then you should still consider upgrading, but you will need to ensure that PHP 5 is available, and either upgrade to it, or pester the appropriate people to do so. This can be a problem for users of a shared hosting environment.

I’ll leave you with a short piece of “advice” from a friend, who, upon hearing that 1.10 was “out”, screamed, “RUN FOR THE HILLS”.

Well, just to make it official; I’m no longer a toolserver root, having resigned from those duties as of early this month for various reasons. Don’t come running to me with requests to have users, processes or queries killed, or packages or other things installed or compiled, ’cause it ain’t going to happen.

While a lot of people know what Wikipedia is, or at least, know it exists, a lot less people know that behind the Wikimedia projects (Wikipedia, Wikinews, Wikibooks, etc.) sits the Wikimedia Commons, which aims to become a repository of free media, including all manner of graphical goodies, audio and video. Commons is driving much of the need to develop better media support in MediaWiki, as referenced in a previous post.

The administrators on the Commons work damn hard to ensure that the content uploaded is free, and for the most part, do a good job. The main problem that seems to be developing right now is the deletion of images on Commons, and the reason that’s a problem is because when Commons sneezes, Wikimedia gets a cold, or less metaphorically, if Commons deletes an image, that image stops being available to all the Wikimedia projects, and a bunch of pages including that image breaks.

Of course, some of this deletion is needed, but there’s also a lot of carelessness going on. While I appreciate that we do need some sort of tracking mechanism to keep tabs on pages using those images, I think it’s important to note that applications such as InstantCommons, which is under development, and aims to allow third parties to use the Commons repository, depend on that project not deleting a ton of images.

One example that sparked this little rant is http://upload.wikimedia.org/wikipedia/commons/7/7d/Bug.png – it’s a little cartoon bug, and we use it on the MediaWiki BugZilla. We’ve been asked to change this, although we haven’t been given a good reason. I rather suspect that, sooner or later, the image is going to be deleted, although as of writing, it isn’t tagged for deletion. All this does is break a bunch of links to the image and causes some inconvenience.

Now, if InstantCommons starts being used (and I gather an alpha or beta of some sort is not far off), then it’s going to be useless if stuff gets deleted. If wiki operators notice that images can’t be relied upon to be in one place, then they’ll just stop using the Commons.

The Commons, as a project, needs to wake up and realise that it’s responsible for providing images to more than just Wikimedia now, and as far as I can tell, this was always the case. If they start breaking stuff, then we might as well abandon the idea altogether.