Popularity Contest for Pages

Thursday, 22 September 2005

I’ve been enjoying Alex King’s excellent Popularity Contest plugin for several weeks now. It’s fascinating to see which posts are being viewed, commented, tracked and pinged, all through the one interface. After using it for a while, I thought of a useful way to extend it and also found and fixed a wee problem. Perhaps these changes will make their way into the next version of Alex’s plugin, but till then you can always download my version from here.

Count Pages

The first extension was to include WordPress Pages as well as Posts in the statistics. Some people don’t use Pages at all, but I use them a lot on Semicolon; in particular, I use them for my WordPress plugin homepages, which are some of the most popular pages on the site. I wanted them to be included in the popularity contest, so I made the following changes to Popularity Contest:

To make sure Page views are tracked, I changed if (is_single()) to if (is_single() || is_page()) in the tracking code. Nice and easy.

To make Pages appear in the reports, I changed the SQL code in various places from post_status = 'publish' to post_status IN ('publish','static'). This includes Pages, which always have status set to ‘static’. I didn’t change this everywhere, because some reports should not have Pages included — Pages do not fall within the normal chronology of Posts, so should not appear in date-based reports.

Conflict with other plugins

A couple of weeks after I installed Popularity Contest, it suddenly stopped working — the statistics were no longer being updated. I eventually figured out that Popularity Contest is incompatible with the Google Sitemaps plugin, which I installed at that time. The Google Sitemaps code includes a WordPress admin include file for some of its function. Unfortunately, Popularity Contest checks for the existence of an admin function to decide whether a view is coming from an admin page. Therefore, with Google Sitemaps enabled, Popularity Contest always thinks it’s on an admin page and therefore never updates its stats.

The fix is simple; delete Popularity Contest’s is_admin_page() function and use WordPress’s built-in is_admin() function instead. This function effectively checks whether the URL contains “wp-admin/”, which as Alex says is not the best idea:

Initially, I just did a check in the URL for wp-admin, but that’s really not a good solution. I had an IM chat with Dougal and he first suggested checking for get_bloginfo(‘wp_uri’).’/wp-admin/’, but we decided that sub-domains could be problematic there. Then he suggested checking of the existence of a function from admin-functions.php. This seems like the best idea to date and it will be in the next release of the plugin.

The problem with this approach is shown up by the Google Sitemaps conflict — there’s nothing to stop another plugin from including admin-functions.php, which will break the admin page detection. I feel it’s best to use the built-in WordPress function — it’s less likely to cause obscure incompatibilities, simply because it’s in the WordPress core.


Finally, my version of Popularity contest switches off the default popularity display per post. I like it like that.

Download the tweaked version of popularity-contest.php. To install, just copy it over your existing version. My modifications to popularity-contest.php are in the public domain. Share and enjoy.



You can leave a comment, or trackback from your own site.

  1. Thanks for the tweak.

Leave a comment