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.

Published by


Dave Slusher is a blogger, podcaster, computer programmer, author, science fiction fan and father. Member of the Podcast Hall of Fame class of 2022.

11 thoughts on “Popularity Contest: WordPress Plugin Hall of Shame”

  1. Alex says:

    Actually, I tried to reproduce this 3 times and never could. My guess at the cause was a MySQL permissions issue that was causing the ALTER statement to fail, but that’s why I sent folks to the HelpCenter, so they could get support. It’s a beta, betas have bugs. 🙂

    Thanks for your contributions to Open Source.

  2. nogeek says:

    you saved my time man.. thanks alot. wp_die is too much for this isnt it ?

  3. Shannon says:

    Hmmm – and now your blog page even loads faster…

  4. dave says:

    Alex, You didn’t have to guess if you actually looked at your own code. Multiple people reported the issue and you kneejerk sent them all elsewhere rather than checking your own logic. You can’t both excuse this as a beta and also have it in the plugin automatic upgrades. If it isn’t ready, don’t put it in there.

    nogeek, glad I could help.

    Shannon, I think most of the time you should be getting the SuperCache version

  5. Vince says:

    Hello there!!! I am having the same problem. What do you mean by “commenting out wp_die”? You mean erasing this code?

    Please do help. My site is totally blank and I can no longer access anything including the my admin page, log in page, etc…. grrrr… I wish I did not installed this plugin.

  6. dave says:

    Vince, you have a few options but all of them involved accessing the file system of your server box, either via ssh/telnet or some kind of web interface. I’ll assume you are able to do that with your web host if you were able to install the plugin in the first place.

    1) You could physically move the entire directory with the plugin to somewhere else. It currently lives in /wp-content/plugins . If you move it anywhere else, like your home directory or /tmp that should get your blog at least functioning again.

    2) If you open the popularity_contest.php (sorry, I deleted all this stuff so I don’t know the exact names anymore) and find the line with the wp-die command in it, just add the characters


    in front of that and it will stop happening.

    3) If you have access to your database, you can drop the table wp_ak_popularity_options (the command “show tables” will give you the names of everything if it has a different prefix than wp_ on your system.) From mysql:

    drop table wp_ak_popularity_options;

    If you do that, it will try to install.

    4) There is a newer version of the plugin available that if you can install by hand over the old one is reported to fix this issue.

    I hope one of those options works for you. It sucks, I know.

  7. Vince says:

    To be honest, what Alex did is almost like killing our blog. I am not a techie person, and I could have start all over again without knowing the problem.

    I do hope that you will be more like a righteous man Alex. It’s a good thing that I discovered it and tried to do some research and I’ve known Dave. If not, I could have deleted and kill my 1 year old blog. What you did is not just right.

  8. slobjones says:

    I’ve uninstalled the Popularity Contest plugin but noticed it apparently left behind two tables titled wp_ak_popularity and wp_ak_popularity_options.

    Can I safely drop these tables?

    1. dave says:

      I’m pretty sure you can safely drop those tables if you are done with the plugin.

  9. wrench says:

    I use Popularity contest and I am glad I found this before attempting an upgrade. BTW, Alex King is also the author of the ligit plugin, which I also had issues with.
    I understand that no software is perfect and will have bugs or deficiencies. It is inexcusable to a) introduce issues (using wp_die) b) be flippant when dealing with you clients. They ARE you clients even if they do not pay you directly.

  10. Great post. I too have had significant problems with Popularity Contest, including the ones you’ve mentioned in this blog. After enabling the plugin, my entire blog just went blank – not even an error message, just a totally blank page on all admin pages and front-end pages. Crazy!

    I finally installed it by clearing out the old Popularity Contest DB tables (although the installation had a “fatal error” upon installation it still “worked”) – and once I was able to get it functioning I found that it didn’t seem to work with WP-Supercache and was using MASSIVE amounts of my server’s resources!

    After reviewing Alex King’s blog, my conclusion is this – the guy is just arrogant, and that’s all there is to it. What he SHOULD do is let Popularity Contest die gracefully so that another hacker (or team of hackers) can pick up where he left off and make the plugin work better – it’s a great idea, but as long as his Popularity Contest plugin is out there, nobody’s going to sit down and make a better one.

    I too, am removing Popularity Contest from my blog, for all the reasons you’ve mentioned, and then some, although unfortunately I’ve heavily integrated it into my site’s theme, which means that removal is going to be a lot harder than simply deactivating the plugin.

    Thanks for opening our eyes to this plugin’s nefarious ways! Hall of Shame, indeed.

Comments are closed.