No Mr Bond, I Expect You To wp_die()!

After my argument with Alex King the other day where he defended his use of a “wp_die()” call from his WordPress plugin as being a completely appropriate thing for a plugin author to do, I got curious. I have 27 plugins on this blog, 12 active and 15 inactive. I deleted the two I had installed that Alex authored so they are not included in this count.

I did a grep on wp_die from my wp-content/plugins directory. I found 6 occurrences of it – 5 from Tantan Spam and 1 from WP DB Backup. Tantan spam is using it as the mechanism of comment spam fighting. When it has determined that the incoming comment has not proved to be from a legitimate commenter it uses wp_die to bail and not post the comment. WP DB Backup use it in the error handler when the type is “fatal”, which includes things like lacking permissions to write files or trying to download backups when not an admin user and such.

So, out of my 27 plugins only 2 use it at all and both of those are in specific transactions. I stand by my point that the use of wp_die for any plugin on an ordinary configuration error is wildly inappropriate. Because the routine that tried to load popularity contest’s configuration was ultimately called on every page load, this completely killed every single page of my blog. Alex continues to defend his code as standard procedure and the situation that I and others were in as “whacked out config” . It was the config his previous version of the plugin set up and ran with for over a year. I’m not really incensed about the error so much as the not caring, the blaming of us, refusing to accept that his logic was bad and his handling was worse, etc. Crowd Favorite is not currently my favorite, that’s for sure.

PS – All of this had me wondering exactly how hard it is to write WordPress plugins, so I fiddled with the Digest Post one to add admin pages and to get and write its options from the database. It’s not too difficult and is kind of fun. I emailed the author of that plugin and offered to either send him patches or take over as maintainer of it. We shall see.

Popularity Contest: WordPress Plugin Hall of Shame

Yesterday I had my first ever bad experience with a WordPress plugin auto-upgrade and it was really really bad. I did the auto-upgrade of the Popularity Contest plugin, first upgrade in a very long time. These upgrades have become so routine that I don’t much think twice about executing them any more. I clicked the link and BANG my blog stopped working. Completely. Totally. All pages, including the wp-admin pages, said:

Error: Popularity contest cannot be installed.

I had to move the plugin out of the directory in order to get anything to work again, then I had to clear my SuperCache as the non-functioning pages had been cached for some of them, like the all important front page.

This morning before work I took a few seconds to look at it, and I found some egregious code. The plugin has a get_settings() method which has this code (forgive the white space munging):

// If the DB tables are not in place, lets check to see if we can install
if (!count($settings)) {
// This checks to see if we need to install, then checks if we can install
// For the can install to work in MU the AKPC_MU_AUTOINSTALL variable must be set to 1
if (!$this->check_install() && $this->can_autoinstall()) {
$settings = $this->query_settings();

if (!count($settings)) {

// trigger_error('Popularity Contest Cannot Install', E_USER_WARNING);
wp_die('<b>Error:</b> Popularity contest cannot be installed.');

Now, this appears to have a couple of really bad problems. One, it is doing wp_die for a configuration problem! Seriously, WTF? I think that violates the contract between a plugin and the main WordPress process. If you have some sort of problem, die gracefully rather than just shutting down the whole blog. Second, it seems like my case will always trigger that die. The $settings array comes from:

select * from wp_ak_popularity_options;

I had the plugin previously installed so that it didn’t need to install but I was running all default options so that my wp_ak_popularity_options table was zero rows. At this point, the plugin decided that was such a bad problem that it needed to shut down all of WordPress including the wp-admin pages you would use to create those option records. Oh boy.

What I did to get back running was to comment out the wp_die line. At that point, the plugin actually installed and I was able to get to the settings page for it. I did a “Save” even though I had all default values just to get rows into that table. Now my table has 4 rows in it and presumably even if I do another automatic upgrade this one should keep working. This plugin is now on my watchlist, though. It’s burned me hard once.

I think for people having this problem just commenting out the wp_die line will get most or all of them back up and running. I’m not sure what the thinking was that went into this logic but it was a really terrible bit of thinking with really severe consequences. Not to the WordPress plugin author community: calling wp_die is really fricking serious. Don’t do it unless continuing to run will delete the blog. Otherwise handle your problems yourself.

Update: For bonus points in the version I have installed, the setup page gives you code to cut and paste into your template that doesn’t actually work. It tells you to use:

show_top_ranked_in_last_days($limit, $before, $after, $days = 45)

when in fact the actual function is:


The former is an internal one not available outside the plugin. The latter is the external API call that is available to your template.

Update 2: I’ve opted to remove the plugin as well as the WordPress Mobile Edition by the same guy. The author takes shutting down my blog too lightly, and defends this whole thing with “hey, it’s a beta so what do you expect?” I was installing via the Plugin GUI on my WP Admin page. If it was risky, I had no way of knowing that unless seeing a “b” in the version number was supposed to communicate that. Over on his plugin page, Alex King defends the use of the wp_die call as being reasonable. I don’t see that rendering the blog unusable is a reasonable way to deal with it, even if the configuration tables were missing. His code wasn’t even checking that, as it treated an empty table as the same as a not-created table. Bad juju.

Alex, thanks for your time in creating this plugin. I appreciate the use I got out of it for the time I did. However, my blog is important to me and I can’t have plugin upgrades shutting it down.

Popularity Contest It Is

I added in the sidebar the results of the Popularity Contest WordPress plugin. If you look at a category, month or year view you’ll see the most popular posts that fit those criteria. Otherwise, you’ll see the most popular of all time. All time I tell you!!

Actually, there is a three-way split in the distribution. When I first fired this up, all the most popular posts were the ones with lots of comments and trackbacks. Today, it is all the ones that are on the front page right now. Anything that doesn’t fit one of those two is pretty far down the list. Over time this will even out but it will take a month or three for the all time posts to make any sense. I like it, though. It seems neat and like the post I made yesterday, all those SEO tool plugins all have the same laudable goal, making it easier for someone that finds your blog by accident to get to material that might interest them.

WordPress Plugins for XMas

My buddy Jason is going WordPress plugin crazy. To be honest, I hadn’t heard of most of these but I’m willing to try most things. I’ve installed the Popularity Contest and Related Posts, just to see how they work. The popularity numbers are kind of bogus right now, since they only have a few hours of page view data. Mostly the rankings are based on the comments and trackbacks right now, but that will even out over time. I’ll add in a “most popular posts” thing in a sidebar at some point. Once you get things as busy as they already are currently, why not go for broke? Let’s busy the living hell out of them!