The Jackal Rants

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.

So, the United States has joined the rest of the world in dealing with climate change. I suppose there’ll be a lot of sniping and accusations of hypocrisy and so forth over the next few weeks.

Why bother? The fact is that, now the US recognises that, whether or not we caused it – and while we might not have caused all of it, we certainly haven’t been helping the situation – climate change is going to affect us in an adverse fashion…now we have another collaborator that’s going to help us work towards a sensible resolution that benefits the ecosystem we all live in.

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.

Excellent little find for Apache HTTP server administrators and advanced web developers; the mod_rewrite cheat sheet is a free, single-page helper that’s available in both PNG and PDF formats and crams a wealth of useful reminders and basic information about rewriting URLs with mod_rewrite, which some consider to be Apache’s answer to Sendmail in terms of power and ease of configuration and use.

That is, the 27th of June; for that is the date upon which Tony Blair will stand down as Labour leader, and with it, relinquish the position of Prime Minister of the United Kingdom. Unfortunately, with a lack of any significant opposition candidates, now that John Reid has announced he’ll be stepping down from the Home Office, this means Gordon Brown will basically ascend to the throne in a glorified coronation.

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.

Right, well, this’ll be brief, but succinct. I doubt any volunteer working with the Wikimedia Foundation can have failed to notice the recent debacle over the new Board resolution mandating confirmation of identity and imposing a minimum age on volunteers working with “sensitive data”, which is poorly defined as “developers with access to sensitive data”, as well as CheckUsers (which makes sense) and OTRS volunteers, which makes less sense.

Daniel Kinzler put together a +1 insightful post for his blog, which summarises a lot of the major concerns I’ve seen over this proposal, including the lack of research beforehand, the lack of thinking regarding an effective implementation and the lack of communication to the people it affects.

I breezed over the “next generation MediaWiki” issues in the last post, but at least one person saw fit to comment on a particular part of it, so I feel obliged to post a bit more about it, with a clarification.

For some months, there have been discussions on the wikitech-l and mediawiki-l mailing lists regarding the next version of MediaWiki after 1.9. Brion Vibber, our lead developer and release manager, has stated that this would be 1.10, due for release this month or early next, and this sparked off a whole discussion about “MediaWiki 2.0″.

The problem (I feel, and it seems, so do some others) with labels such as “MediaWiki 2.0″ is that it encourages people to start planning for a big rewrite with a whole raft of new features, and we had some mailing list posts discussing this. Now, I’m not going to defend the entire code base and state that parts of it don’t suck, and I’m not going to get into a language war, either, but I don’t feel (and again, others actually working on the software agree) that a full-blown rewrite from scratch is at all the approach we need to take; our existing model of continuous development and integration works for us, and it works well.

There’s been a lot of time and effort invested by many people in developing techniques and experience for all aspects of running the Wikimedia cluster, including actual application development, optimisation (including SQL optimisation, etc. and a lot of trial and error) and the entire server operations side of things. A major rewrite of MediaWiki would discard much of this hard work, and would discard something that a lot of people have worked on since 2003.

Therefore, I was skeptical, as were a lot of developers, over the claims of some people that we needed to rewrite MediaWiki for version 2.0. This seems to have been the general consensus at a recent conference in Vancouver, and while I didn’t attend it, I’d like to think some of the comments I made on the general issue prior to that did something to help convince people. (Satisfied, Erik?)

So, as I mentioned before, the outcome of that was that the mediawiki-ng-l mailing list was set up. It’s on moderated subscriptions at the moment, but as explained in the introduction post, membership is not a difficult hurdle, although I am concerned that it seems to be adopting a secretive attitude.
With a bit of luck, we have a think tank established that will begin churning out useful ideas soon. With even more luck, that think tank will remain open to all of us…