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.

3 thoughts on “wordpress mu and akismet: wordpress_API_key problems

  1. Hey Matthew – you’re doing something vaguely related to what I’m trying to achieve, but there’s a slightly easier (well, more correct, don’t know if it’s actually any easier) way to do this. When you add your hook:

    add_action(‘wpmu_new_blog’, ‘verify_key’, 10, 2);

    add the 10 (priority, 10 is default) and 2 (number of parameters your function accepts). Then change your function to:

    function verify_key( $blog_id, $user_id ) {

    and you’ll get the blog id and user id (of the admin) passed to your function when it’s called. Then you can use something like get_blog_details() to load up info about the blog.

    I’m still trying to figure out why I can’t call another function that creates tables from that hook tho :-/

    Cheers, Beau

  2. Hi Beau,
    Ah right, cheers. That certainly would be a less hacky way of doing things than I did them.
    I still find it strange that Akismet isn’t really set up with WPMU in mind, and that none of this is particularly well-documented. eg. having to call akismet_http_post() manually when a new blog is created.
    There is also definitely a bug in akismet_stats_display() because it completely ignores a hardcoded $wpcom_api_key value which you were promised would be used if set.
    Anyway my process for auto-registering each new blog with an Akismet key does seem to work.
    Cheers!

  3. Matthew, handy post. I didn’t test this, but you should be able to simplify verify_key by taking advantage of the fact that wpmu_new_blog passes along the new blog ID.

    // Untested.
    function verify_key($blog_id) {
    switch_to_blog($blog_id;
    akismet_verify_key(‘your key’); // however you want to get the key.. site option, etc.
    restore_current_blog();
    }

    This will tell WP to behave as if $blog_id were your new blog while you call akismet_verify_key, then sets it back to the blog you were on when creating $blog_id.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>