Themes and WordPress 3.0 some important changes

During the development of WordPress 3.0 we have made a number of changes under the hood which will be of interest to the developers and users of themes.  Some of these changes are about making themes easier to develop and some of them are about making it easier to support the override of parts of themes.

1) get_template_part – [13146], #12371

The first change which should make it easier for extensible flexible theme development is the introduction of get_template_part() which has been introduced as a generic way of modularising themes a step beyond the basic footer/body/header files.  This new function makes it very easy for a theme to reuse blocks of code implementing theme areas such as the WordPress loop in a way which makes it easy for a child theme to override the implementation in a context sensitive way.

This function is really easy to use – You create a file within your theme containing the code you want to re-use and then you pull it in as follows:

get_template_part( 'loop', 'author' ); // Pull in the loop for the author archives

This will look for the files loop-author.php and loop.php searching first in the current themes folder before looking in the parent themes folder (if one if defined).  The new TwentyTen theme in WordPress 3.0 uses this for every call to it’s loop.php to make it easy to override in a single instance from a child theme.

2) Deprecating overly minimal themes [14365], #12425

The next change is to deprecate the support for overly minimal themes.  Prior to WordPress 3.0 any theme which was using the relevant template tag but missing any of the following template files – header.php, footer.php, sidebar.php, comments.php, comments-popup.php – would effectively behave as if it has a parent theme defined as ‘default’ using the relevant files from the old default theme.

Now that we are moving to a new default theme we didn’t want to have to support this very old behaviour indefinitely or make it such that the files from the TwentyTen theme were used as they have a different visual layout and would like change peoples existing sites.

Going forward a WordPress theme using the relevant template tags is expected to contain all these files itself, or have them provided by a parent theme, and the theme compatibility files included in WordPress 3.0 will be removed in a future version.

If you are using a theme which is affected by this change then you just need to make sure that you have the default theme installed – it will not be in new installs but will be preserved on upgrades. Then add the following to the comment at the top of the style.css of your theme to make it such that the default theme is used as its parent theme:

Template: default

More information on the process of indicating a parent theme in a child themes style.css is available in the codex.

Giving your WordPress a check up

Every now and then someone finds something wrong with a WordPress install which, rather than be caused by a bug in WordPress itself, is caused by a server configuration error, an interaction between WordPress and something else installed on the server or is just a recommend optimisation for better site performance.

Everyone has a different set of pitfalls that they have come across and I would like to collect together all these little things into a comprehensive community developed plugin which can hopefully become one of the first “canonical” plugins that we have talked about.

To that end I have developed a framework for this plugin, in the style of a unit test framework, to make it really easy to write tests and I am hoping that some of you will have ideas for tests and also that you will want to get involved.

For a while I have tagged tickets in the main WordPress trac where there are is possible inspiration for tests – http://bit.ly/healthchecktickets.

The following is an example of the code required to carry out one of these tests which recommends users of PHP4 upgrade to PHP5.

/**
 * Check that we are running at least PHP 5
 *
 * @todo Provide a link to a codex article
 * @link http://core.trac.wordpress.org/ticket/9751
 * @author peterwestwood
 */
class HealthCheck_PHP_Version extends HealthCheckTest {
    function run_test() {
        $this->assertTrue(    version_compare('5.0.0', PHP_VERSION, '<'),
        sprintf( __( 'Your Webserver is running PHP version %s, which is no longer receiving security updates and will no longer be supported by a future version of WordPress.', 'health-check' ), PHP_VERSION ),
        HEALTH_CHECK_RECOMMENDATION );
    }
}
HealthCheck::register_test('HealthCheck_PHP_Version');

If you would like to get involved in the development of the plugin then you can check the source code out from the WordPress plugins subversion repository here: http://plugins.svn.wordpress.org/health-check/branches/alpha/ and you can follow the development progress using the WordPress plugins trac here: http://plugins.trac.wordpress.org/log/health-check/branches/alpha.

As the plugin is not yet ready for its first release we will be doing the development in this alpha branch and then move to trunk once we make the first release.

I am actively looking for fellow developers for this project as a community team we can make this a success.

So if you would like commit access to write some tests then drop me a note using the contact form with a bit about yourself and I will give you access.

What should go into a WordPress maintenance release?

Now that WordPress 2.9 has hit the streets there are inevitably going to be a number of bugs which slipped through testing which people will identify and we need a good process for deciding which of these bugs should be included in an upcoming 2.9.1 release and which of them can wait until 3.0 to be fixed.

In the past I think we have included to many changes into the maintenance releases.  This has partly been due to the lack of end-user testing which has taken place during the beta phase and partly based on a drive to fix bugs sooner rather than later.  This has had the unfortunate downside of diverting the time of the core contributors, that they could have been spending on working on features for the next major release, and has meant that the release cycle has been extended to longer than we would have liked.  This means that you don’t get the cool new features like Trash as soon as you would have done.

This post is an effort to summarise my thoughts on this subject and I would welcome discussion in the comments below – hopefully we can come up with a succinct set of criteria which will may it clear to everyone what the community thinks should be included in a maintenance release and what should not.

First of all I think it is important to understand the purpose of a maintenance or point release.  To me these releases are about fixing critical bugs which affect a large percentage of end-users and disrupt their ability to use the software. They need to have a small number of changes so as to make them easy to test, lightweight to develop and to reduce the impact on the next major release. This also means that they will be easy to upgrade too and are less likely to break plugins / themes in the process so making the upgrade to them even easier and more worry free.

If we let the content of these release grow too large then we will never have the time to work on the new features for the next major release which will then mean that release takes longer to arrive and may end up with less features.  We also need to remember that every change has the risk of introducing a new bug and this is another reason we should limit the number of changes in a maintenance release.

Now we need to identify what sort of bugs fit into the category of critical bugs.  The most obvious and easiest to identify are the security bugs – fixes for these need to be available as soon as possible. Once we get beyond security bugs it can get more difficult to quantify the affect of the issue and therefore how soon a fix needs to be in the hands of the users.

The following list of criteria are my straw man proposal on this subject:

• The issue is easily reproducible and testable.
• The issue is severe – e.g. it makes a whole feature unusable and therefore the fix cannot wait for the next major release.
• The issue is a regression from a previous major release – for example if an unintentional/incompatible change to an API or UI was made.
• The issue is not just that warnings or notices appear when WP_DEBUG is enabled the area of code in question must also fail to work correctly.

What do you think?

Beta Testing in your language

Thanks to Naoko McCracken the WordPress Beta Tester plugin is now fully translatable and also has a Japanese translation out of the box.

WordPress Beta Tester with Japanese translation enabled

Hopefully this will make it easy for Japanese WordPress users to get involved in the Beta Testing of WordPress 2.9 in the coming weeks. If you would like to submit a translation for your language then you can download the pot file from the WordPress plugins Subversion repository here: wp-beta-tester.pot. If you send me the po and mo files I will add them to the repository and release an updated version of the plugin.

Backing off Blog-by-email

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

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.

Making it easy to be a WordPress Tester

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.