Here are some of the statistics. On WordPress Informer, when it was very new (less than a month old) it had only 7 posts, and had received roughly 2000 pageviews. That’s pretty low, but lets take a look at it. About 700 of those visits were to the home page and about 1300 were to single post pages. If you only show related posts on single post pages (which is how we currently do it on there) then the related posts plugin has been run over 1300 times for only 7 posts, which is roughly 185 times per post! If I were to show related posts for each post on the front page then it would have run another 4000 times (which is a conservative estimate), bringing it to 757 times per post. If you think this seems excessive, lets take a look at the stats for Web Developer News. It has had over 13,500 page views in the last 30 days. About 750 were to the home page, about 140 were to other static pages, roughly 550 were to tag pages, and another 250 were to miscellaneous pages such as search pages. That leaves 11,810 visits to single post pages and 21 posts during that same time. That’s about 562 times per post! If I added related posts to the home page, tag pages, and search pages it would need to be run roughly another 15,000 or 1,276 times per post.

In addition to the simple waste of memory and cpu cycles, putting the calculation of related posts on the front end means that when they start to slow down your users are left with a bad experience and slow loading pages. And they will slow down eventually, if your site gets big enough. I just recently worked on a site with more than 6,000 posts and over 1,800 tags (they offer investing advice, and have a lot of tags that correspond to ticker symbols). At that point, some of the related posts queries were taking 10 seconds to run. That’s really slow. We can do better than that right? Well it’s not easy but I think we can.

Efficient Related Posts moves all this effort into the admin section, finding related posts when a post is saved rather than when the user views it. The advantage is that if the query is slow it happens less often and the post writer is the one that waits rather than the user (which I think is WAY better).

There are limitations. For example, since the related posts are stored as post meta data, we only store a certain number of them (10 by default, but you can set it to whatever you want). This means that if you decide you need to display more than 10, you need to have the plugin re-process all posts. I generally display up to 5 related posts, but store 10 just in case I decide to display more in some areas. Also, since the related posts are calculated when a post is saved, manually adding a tag through the database will have no effect on the related posts, although I recommend not doing that anyway.

Requires PHP5.

Please discuss this plugin on the WordPress Twitter Widget page.

You can use the helper functions to display the related links in your theme or you can simply tell the plugin to automatically add them to posts or even just single posts. The list of links is output as a semantic unordered list (ul) with an optional title. Everything is well classed to make CSS styling easy.

This plugin is not an automatic solution like many related posts plugins, but works well for people who want total control of the related links (or have multiple sites they want to link between).

Worried about hotlinking to images that load slowly? Don’t! This plugin will cache the 20 most recent design thumbnails in a directory inside your uploads directory. They’ll load as quickly as everything else on your site. Then, when they get too old to show in the widget, they are removed, which means they’ll never waste space on your site.

If you want to see this plugin in action, check out Web Developer News or Attackr – Designer News.

Please discuss this plugin on the Wordpress Twitter Widget post.

Please discuss this plugin on the WordPress Google Analytics Plugin post.

Regarding the anonymous statistics collection, as my plugins are getting more and more popular (1000s of users now), I’m struggling to keep in touch with my plugin users. Gathering some statistics will help me to design my plugins to meet the needs of the users. This is not meant as an invasion of privacy, and you can easily disable it from the options page.

Here is the data it collects and sends:

Plugin Name

I plan to eventually add this to more of my plugins, so this is used for me to tell sort the data by plugin.

Unique identifier

This is a hash (one way encryption) of the URL and a random number. This simply helps eliminate duplicate info from being added to the pool of data.

Plugin Version

Just the version of the plugin.

PHP Version

Most of my plugins require PHP 5+, but not all of them and I would like to update the ones that don’t. I’m hoping to see how many users are on an old version of PHP.

MySQL Version

Certain database queries can be vastly optimized on newer versions of MySQL, so this information could be very helpful.

Server Software

Microsofts IIS can cause a lot of problems for PHP applications, so knowing how many users are using IIS is important.

Memory Limit

Your web server puts a limit on the amount of memory a script can use. This plugin should never come close to an average memory limit, but this is a statistic that will be nice to keep in mind as new plugins are developed.

For those that want to know, here is the code that collects the data:

$s['plugin'] = 'Twitter Widget Pro';
$s['id'] = $this->get_id();
$s['version'] = TWP_VERSION;

$s['php_version'] = phpversion();
$s['mysql_version'] = @mysql_get_server_info($wpdb->dbh);
$s['server_software'] = $_SERVER["SERVER_SOFTWARE"];
$s['memory_limit'] = ini_get('memory_limit');

Please discuss this plugin on the WordPress Twitter Widget

I just uploaded version 1.2.0 of my WordPress Google Analytics plugin. It includes some minor bug fixes, and updated options page, and optional anonymous statistics collection. As my plugins are getting more and more popular (1000s of users now), I’m struggling to keep in touch with my plugin users. Gathering some statistics will help me to design my plugins to meet the needs of the users. This is not meant as an invasion of privacy, and you can easily disable it from the options page.

Here is the data it collects and sends:

Plugin Name

I plan to eventually add this to more of my plugins, so this is used for me to tell sort the data by plugin.

Unique identifier

This is a hash (one way encryption) of the URL and a random number. This simply helps eliminate duplicate info from being added to the pool of data.

Plugin Version

Just the version of the plugin.

PHP Version

Most of my plugins require PHP 5+, this one does not, but I would like to update it. I’m hoping to see how many users are on an old version of PHP.

MySQL Version

Certain database queries can be vastly optimized on newer versions of MySQL, so this information could be very helpful.

Server Software

Microsofts IIS can cause a lot of problems for PHP applications, so knowing how many users are using IIS is important.

Memory Limit

Your web server puts a limit on the amount of memory a script can use. This plugin should never come close to an average memory limit, but this is a statistic that will be nice to keep in mind as new plugins are developed.

For those that want to know, here is the code that collects the data:

$s['plugin'] = 'WP Google Analytics';
$s['id'] = wpGoogleAnalytics::get_wgaId();
$s['version'] = WGA_VERSION;

$s['php_version'] = phpversion();
$s['mysql_version'] = @mysql_get_server_info($wpdb->dbh);
$s['server_software'] = $_SERVER["SERVER_SOFTWARE"];
$s['memory_limit'] = ini_get('memory_limit');

Please discuss this plugin on the WordPress Google Analytics Plugin post.