Making your broken Plugin work again with WordPress 2.8.1

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.

Changelogs, Changelogs, Changelogs

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.

WordPress weekly digest 11th February to 17th February 2008

It has been a busy week again for WordPress 2.5, the changes this week were:

• Introduction of the beginnings of a plugin update system (#5586).
• Changes to allow uploads to be stored outside of the WP path and have custom URLs ([6780]).
• A fix for the human readable time offset for future posts (#5817).
• Change to using the full slug rather than the abbreviated one when editing (#5816).
• Reduction of the number of SQL queries made by wp_count_posts() (#5820).
• Changes to make a nonce mismatch fail instead of showing an “Are you sure?” message (#5838).
• Improved metadata for atom comment search feeds (#5493).
• Allow is_single(), is_category(), and is_tag() to accept arrays of items to test (#5593).
• Addition of random order option to wp_tag_cloud() (#5726).
• Fixes to the markup generated by the Walker class so that it matches 2.3 (#5844).
• Addition of bulk delete to the links manager ([6842]).
• Improvements to the performance of generic_ping() (#5855).
• Changes to make sure private posts stay private when they are published ( #5881, #4206).
• Introduction of more specific moderation emails for {ping|track}backs. (#4986).

On top of all of this there has been a lot of work this week on finishing off the new admin design.

For even more information on some of the other little changes that went in this week you can read the whole weekly trac timeline, look at a complete changelog for trunk or view a diffstat of the changes.