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

Without being alarmist, I find there is quite a lot of buzz online about the swine flu, and it’s possibility of becoming a global pandemic. Since I’m a bit of a health nut, I figured now might be a good time to share some of the ways I’ve come across in recent years, which according to research help boost your immune system.

1. Get enough rest. [1,2,3]
2. Stay calm and reduce stress. If possible, medidate, or perform other activities which reduce stress (stress hormones directly cause apoptosis of white blood cells). Other activities could include being affectionate with your (non-infected) loved ones. [4,5,6,9]
3. Use immune-boosting supplements such as Zinc or Vitamin-C — these supplements do not cure illnesses, but being deficient in them will affect the immune system negatively, and keeping your zinc and C levels high boosts your immune system. [7,8,9,10,11]
4. Do not stop exercising, and if you do not do so already, start: moderate physical exercise causes an increase in white blood cell production. A simple yet effective routine to do *at home*, is to do some pushups, squats, and crunches. Moderate is the keyword though, as complete physical exhaustion is probably not desirable. [12]
5. Eat spicy food, there have been some findings that spicy food, containing for example chili helps boost the immune system or fight illnesses. But mostly it tastes good, and makes your dishes keep longer (that’s why it was invented).

Now I could’ve found more references, and I’m sure there are more articles out there on this subject, so that should excuse my laziness. By the way, I’m not bothering with references for the 5th tip, I think eating spicy food speaks for itself

References.

1. http://www.ncbi.nlm.nih.gov/pubmed/10443758?dopt=A…
2. http://www.springerlink.com/content/wh8185q43g2325…
3. http://myheartmind.blogspot.com/2008/07/immune-sys…
4. http://www.pubmedcentral.nih.gov/articlerender.fcg…
5. http://www.nhs.uk/news/2007/October/Pages/Meditati…
6. http://www.springerlink.com/content/kk477701223g14…
7. http://www.ncbi.nlm.nih.gov/pubmed/7749260?dopt=Ab…
8. http://ods.od.nih.gov/FactSheets/Zinc.asp
9. http://my.clevelandclinic.org/disorders/chronic_fa…
10. http://www.positivehealth.com/article-view.php?art…
11. http://www.ltdk.helsinki.fi/users/hemila/immunity/
12. http://www.nlm.nih.gov/medlineplus/ency/article/00…

Quick post, since others face the same problem. When I updated I added a captcha plugin to my site, since I was getting about 10 spammers registering per day. This means that you need to enter a captcha phrase to register as a commenter here. If you however entered the wrong phrase, you were confronted with the lovely error:

Fatal error:  Cannot use object of type WP_Error as array...

A look at the code revealed the plugin to be checking if the captcha entered was correct, and then doing something like this:

$errors["error"] = "ERROR: You must enter the correct letters displayed in the image.";

(I’m not printing it verbatim because I’m too lazy to open the original file)

Obviously $errors (a global) was not an array, but an object of the type WP_Error. Solution: To read up on how WP_Error works, and use it? Easy peasy?

Not quite.

Simply using the preferred $errors->add(’errorcode’,'error message’); didn’t do the trick, in fact changing the code to that caused an even worse behaviour — instead of there being a fatal PHP error, the captcha simply didn’t complain at all, and new users were able to register at will — oh the humanity!

After checking wp-login.php, where they call the hook “register_post”, which the captcha user registration plugin was hooking into, I saw that it calls it like this:

do_action('register_post', $user_login, $user_email, $errors);

Eureka! I can’t simply use the global $errors array, I must use the one supplied to me by the do_action! Immediately I modify the capcc_validateregister function so that it’s declaration takes in 3 parameters, $user_login, $user_email, and the coveted $errors I so hoped to use. Errrrrr, now I got another wonderful error, that arguments 2 and 3 were missing! Oh lord, I was only getting the desired username!

After digging through into the definition of do_action in wp-includes/plugin.php, I found out that it actually loops through all it’s supplied arguments and appends them to a list of arguments which it then uses for all functions which are hooked in to this hook, but each of them has a little configuration variable called “accepted_args”, and upon freshing up on the wordpress plugin docs for hooks, I finally found the answer to my problem.

add_action('register_post', 'capcc_validateregister', 10, 3);

Where 10 is the priority level (10 is default, which I assumed was good enough), and 3 is the accepted_args parameter.

So hooray, captcha works, and now “all” my readers will know how to fix their “Cannot use object of type WP_Error as array” problems:
1. Make sure you are using the right $errors (in register_post case it is supplied as arg #3)
2. Use $errors->add(’errorcode’, ‘message’); instead of $errors['errorcode']= ‘message’;

Hopefully getting point 1 down will be quicker than it was for me, as including the writing of this post, it’s taken an hour of my time! And I really should be debugging a cool app which I’ll blog about later!

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.

That the javascript “escape/unescape” function combo sucks.

If you care about not trashing non-ascii characters for example, stick with encodeURIComponent/decodeURIComponent

Oh and if using PHP, stick with rawurlencode (but I guess everyone knew that one already).

peace