On order to protect email servers from a possible denial of service attack from the blog by email feature of WordPress I have committed a change today to ensure that WordPress will not contact the mail server more that once every 5 minutes however often wp-mail.php is accessed.

Message displayed when rejecting request

The 5 minute interval, is itself, configurable using a define in your wp-config.php file it you wish to set a longer or shorter interval.

You would configure this by adding the following to the wp-config.php:

//Set the minimum interval for wp-mail blog-by-email POP3 connections to 10 minutes

define('WP_MAIL_INTERVAL',600);

This feature will be available in WordPress v2.9

WordPress 2.8.1 contains changes to improve the security of plugins by ensuring that only correctly registered plugin pages can be accessed as well as only showing the link to the page to users who have the capability required in the add_x_page call.

This change has broken a number of plugins which were adding there menus on the wrong action hook bypassing some capability checks.

The correct hook to use, as documented in the codex, is admin_menu. However, some plugins have successfully in the past been using admin_init but this meant that they bypassed some of the capability checking that WordPress does to help limit access to plugins pages.

This capability checking is there to help limit access to plugin added pages but plugins must always use current_user_can() to check the capability they require to ensure they prevent access to incapable users.

The code to look for in your plugins is something like this:

add_action('admin_init', 'my_plugin_menu');

function my_plugin_menu() {
  add_options_page('My Plugin Options', 'My Plugin', 'manage_options', 'your-unique-identifier', 'my_plugin_options');
}

Which should be:

add_action('admin_menu', 'my_plugin_menu');

function my_plugin_menu() {
  add_options_page('My Plugin Options', 'My Plugin', 'manage_options', 'your-unique-identifier', 'my_plugin_options');
}

And don’t forget while checking your plugin for this issue go and check to make sure you use current_user_can() to check user capabilities before allowing them to access your plugin page functionality.

The other day Ryan shared a simple way of switching a WordPress install to the nightly builds so as to get involved with testing.

The only problem with this method is that you have to redo every time a WordPress release is made because it involves hacking a core file and the update mechanism will only offer you a nightly build if you already appear to be running one.

This got me thinking about whether or not you could create a plugin which would allow a blog to always track a particular type of nightly build stream so as to avoid the need to ever hack core files again.  This morning I am please to announce the first release of my WordPress Beta Tester plugin which is inspired by Ryans example but achieves it in a plugin and will keep your blog on one of the two nightly tracks.  The choice you have is:

• Point release nightlies – This contains the work that is occuring on a branch in preperation for a x.x.x point release.  This should also be fairly stable but will be available before the branch is ready for beta.
• Bleeding edge nightlies – This is the bleeding edge development code which may be unstable at times. Only use this if you really know what you are doing.

Once you enable the plugin it will by default switch your blog to the “Point release” stream and if you want to switch to the “Bleeding edge” stream then you will need to go to the Tools … Beta Testing page and configure the plugin there:

The administration panel for the plugin

Please note: Once you have switched your blog to one of these beta versions of software it will not always be possible to downgrade as the database structure maybe updated during the development of a major release.

A Changelog is a very important thing for a project and until recently it wasn’t easy to add one to your WordPress plugin hosted in Extend.  Some plugin authors understood the benefit of providing there users with the information and were adding it in different places but it was not easy to track down where it was and it some cases your only hope was a trail of clicks across the web to the plugin Authors site to hunt down the post detailing what had changed in this version.

For me, a changelog is a very important thing it is all about justifying to your users why they should upgrade to the latest version of your plugin as well as reassuring them that the changes made have been made for specific reasons and helping them to understand the impact the changes may have on there usage of your plugin.

This has been a hot topic of late and we were discussing it on last nights WP Weekly podcast so I set off to see if I could track down the right person to get a change made to give all plugins a separate top level Changelog tab on there WordPress extend page.

This morning to my delight I found that a Changelog feature had been added and now we have a standardised way for plugins to add Changelogs.  Basically there is a new section in the readme.txt standard which allows for you to document your changelog as your plugin develops.  The new section looks like this:

== Changelog ==

= 1.0 =
* A change since the previous version.
* Another change.

= 0.5 =
* List versions from most recent at top to oldest at bottom.

Which produces the follow style of display on the plugins page in Extend:

Example of the changelog output

And the information will also be displayed in a separate tab in the administration section of your WordPress blog by the plugin installer and updater:

The view of the changelog in the WordPress administration pages

So please go forth and update your plugins readme.txt file and let your users benifit from the information about what has changed between versions.

This weekend is special for two reasons, firstly it is WordCamp SF 2009 and I wish I could have made it as it would have been nice to attend the original WordCamp. Secondly it is also your last chance to get tickets for WordCamp UK 2009 at a discounted price.  This is a growing list of confirmed speakers and of confirmed attendees.

Looking forward to seeing some of you there.

WordCamp returns to the UK again this year and we hope it will be bigger and better than last year especially as we have convinced Matt to attend this year.

This years uk WordCamp is in Cardiff on the weekend of the 18th/19th July and tickets are already on sale with an early bird discount rate available until 31st May.

If you would like to get involved we are still firming up the speaker schedule so if you have a topic you would like to talk about of see discussed let us know.

We also have sponsorship opportunities available – more information on sponsorship can be found over on the WordCamp UK website.

Looking forward to seeing some of you there.

At 8:17am GMT today another WordPress milestone was reached. The WordPress plugins subversion repository received it’s 100000 check-in.

Congratulations to Jeff Yen for achieving this. Maybe you should go check out his Google Maps GPS Link plugin.

Following on from the recent 10000th commit to the WordPress.org Subversion repository I thought I would take a quick look back at some statistics from the past a draw a few interesting graphs to look at how WordPress.org has grown over the past few years.  Enjoy!

WordPress release against repository revision number

Time against repository revision number

WordPress release filesize in kilobytes