thoughts of the driverSteinn Eldjarn Sigurdarson on tech, tel, digital freedom and possibly his life..

Thanks to “wildcard”, a benevolent user who informed me how someone was using some of my posts to promote medications against erectile dysfunction, I have now upgrade my WordPress. It was either that or closing the blog — apparently I have registered myself for some planet sites, or am being picked up by some feed aggregators somewhere, and well, I wouldn’t want to propagate spam.

On another note, I actually never published the blog entry below, and I was fast asleep while it was published. It seems the spammer who compromised my entries did so for a sequence of post ID’s, starting with 63 and ending with 69. I guess the spamming mechanism also sets the post_status to published, as I guess this minor rant about JavaScript’s escape/unescape functions was an old draft.

Well, glad to see I have some audience for my varyingly intelligent outbursts anyway.

…. To turn this into a more fun blog post, I’ll write something about my work too:

Yesterday I spent probably 3 hours tracking down various problems related to having two independent modules within Moodle, both relying on and including MooTools. The first problem was easy: One module (a theme actually, which I am developing) was using an older version: MooTools 1.2.0. The other module (a block) was relying on 1.2.1 — embarrassingly but conveniently I wrote that one too, however I only wrote the moodly-blocky wrapping part, while my coworker Christian Glahn did the fancy JS stuff inside. A quick check on things revealed I could replace the older version of MooTools with the new one and voila: no more JS errors and conflicts. (google-help: The JS error was only appearing on my iPhone webkit browser, and something to do with Browser.freeMem not being an object).

But no, this was not the end of my problems, still there were bugs, but mysteriously no errors. For some incredibly “odd” reason, the anonymous function I added to the domready Event in my theme just wasn’t being executed. After severe amounts of searching I came to the conclusion that no one else had the same problem I had, and I was simply doing something horribly stupid and wrong. I started debugging the internals of MooTools, after trying unsuccessfully several times to examine the contents of Events.$events, and never ever finding my theme code in there.

Before starting to chase down this behavior, I had actually had a conversation with Christian where we decided I should simply write a mootools initialization script, which would check if MooTools existed, and if so which version, and try to make some kind of intelligent decision whether to create a couple of script elements and squeeze them into the head. It was at this moment, I realized that the 2nd MooTools inclusion, was of course redeclaring everything, and thus clearing my Events.

Problem solved. Solution: don’t expect things to work when including the same JS library several times from different locations… and don’t be stupid, I guess I’ll have to work on the 2nd one, so time for coffee.

For fun, here is the solution I hacked up, in all it’s glory (no complaints on the iphone either):

/* Checks if MooTools already exists, if not includes it. */

try
{
	if (MooTools.version)
	{
		// We have MooTools, is it recent?
		var numv = parseInt(MooTools.version.replace(/\./g, ''));
		if (numv < 122)
		{
			// old version, anything smart we can do?
		}
		else
		{
			// new version woohoo! do nothing!
		}
	}
}
catch (e)
{
	// Failure, we assume MooTools is not setup, and we include it
	// XXX: check here for prototype/jquery and abort in that case

	var head = document.getElementsByTagName("head")[0];
	var newscript = document.createElement('script');
	newscript.type = 'text/javascript';
	newscript.src = 'path/to/mootools-1.2.js';
	head.appendChild(newscript);
}

Merry times on the internets.