Monthly Archives: January 2009

wordpress mu and akismet: wordpress_API_key problems

A big problem for any blogger is spam comments, and the Akismet plugin for WordPress is basically an essential item. It does its job really well, and on this blog I’m only aware of the occasional bit of spam. Hoorah for Akismet!

But things aren’t quite so smooth if you need to do strange, weird things with your blog. Like set up lots of blogs off one codebase. Sound crazy? Well multiple blogs is actually something lots of organizations and universities need, and the WordPress fork - WordPress MU –  fits the bill brilliantly. In a few seconds you can create a new blog for someone in your organization, and off they go.

Oops

Hold on. Not quite, you need to enter that long impossible to remember API key each time you make a new blog. It’s not hard to copy and paste from the word doc you’ve got saved somewhere on your… oh now where was it again? No, far better would be for WordPress MU to automagically set Akismet up for you each time you make a new blog.

That must be easy? Right? Erm… no, not really.

Deep breath… and on with the technical stuff

The latest version of Akismet at time of writing doesn’t work in the way described at the top of the akismet.php file. Supposedly if you hard-code your API key into $wpcom_api_key this will fix everything. This simply doesn’t work, thanks to a coding oversight in akismet_stats_display(). In that function, $wpcom_api_key is mentioned as a global variable, but isn’t actually used anywhere in the function. So much for that piece of magic. Maybe in a future version?

The second problem is that even if you have your wordpress API key entered in your database, it won’t have any effect until the key has been registered with Akismet, behind the scenes. I couldn’t find any documentation on this anywhere, but akismet_verify_key() seems to be where this process is actually going on.

Not finished yet. You can’t just make your own plugin to call akismet_verify_key() each time a new blog is created. Sadly akismet_verify_key() contains a call to get_option(‘home’) for the much-needed blog url. Because you’re in the process of making a new blog from an existing blog’s admin area, get_option(‘home’) returns the url of the existing blog, not the new one that you’re interested in.

Sigh.

My solution

Build your own verify_key function, as follows:


function verify_key() {
  global $akismet_api_host, $akismet_api_port, $current_site;
  $key = 'myapikey';
  $blog = urlencode('http://' . $current_site->domain . '/' . stripslashes(htmlentities($_POST['blog']['domain'])));
  $response = akismet_http_post("key=$key&blog=$blog", 'rest.akismet.com', '/1.1/verify-key', $akismet_api_port);
}

Stick this in a plugin of your own making. Note that the awkward way of setting $blog is needed because we have no other way of retrieving the URL of the blog we’re in the process of making, rather than the one we’re currently at while making the new blog… if you see what I mean. In fact, in the newly-released WordPress MU 2.7 you can use this line instead:

$blog = urlencode('http://'.DOMAIN_CURRENT_SITE.PATH_CURRENT_SITE.stripslashes(htmlentities($_POST['blog']['domain'])));

Not much difference, but maybe a tad neater. The choice is yours. 

Now add in:

add_action('wpmu_new_blog', 'verify_key');

to make sure the function gets called every time a new blog is made.

And there you go! A lovely hacked solution to a problem which could be resolved with a bit of tweaking to the Akismet plugin. To be fair, WordPress MU is a fairly new thing, and I guess the guys who wrote the Akismet plugin haven’t had a chance to really test is fully with WordPress MU.