WordPress.org

As we near completion of the 2.9 milestone, it’s that time of dev cycle again, when we ask all you community developers who’ve been putting off contributing to core to dust off your dev environments and help us get closer to being release-ready. How? Bug hunts! Yes, that time-honored tradition (in the time of WordPress, anyway) of everyone pitching in to test patches and report the results, working on solutions to major bugs, and helping to clear out Trac has come around again, and we’re scheduling not one, but two bug hunts over the next couple of weeks to ensure that everyone has enough time to prepare and participate.

#1 – The first bug hunt of 2.9 will be Thursday through Saturday, November 5-7, 2009. This should give people a few days to plan for it, upgrade their dev environments if they haven’t been following trunk, and figure out how to allot their time. We’re stretching over both weekdays and weekend to try and accommodate everyone’s schedule.

#2 – The second bug hunt will be a week later, Saturday through Monday, November 14-16, 2009. This should make it possible for anyone who needs more than a week to set some time aside to participate. This bug hunt will coincide with WordCamp NYC, where a special Hacker Room will be set aside for people to go and work on 2.9 bug tickets alongside regular core contributors including Mark Jaquith and Matt Martz (sivel from IRC).

The Goals

Test, test, test existing patches! You can see all tickets with patches that need testing by checking this report. When you’ve tested a patch, report your results in the ticket comments, so core committers can see how the patch is faring.

Fix known bugs! You can see the bugs that need patches by checking this report. Look for the ones that seem that they’ll affect the most people or have the biggest impact by being fixed. Edge case bugs should be lower priority.

Report new bugs! As you’re testing out the development version, if you come across a bug, search trac to see if someone has reported it yet. If so, add a comment with your experience to the ticket so we’ll know it’s affecting more than one person. If no ticket exists yet, create one.

Core committers will be around (in the #wordpress-dev channel at irc.freenode.com) both weekends to review patches that have been thoroughly tested, answer questions as needed, and give feedback on patches that need more work before being commit-worthy.

If you’ve never participated in a WordPress bug hunt before, but you’d like to get involved, we’d love to have you join us! To prepare, you’ll want to set up a test environment, start using the current development version/maybe install the beta testing plugin, join us in the #wordpress-dev IRC channel, and read up on automated testing.

The number one reason people give us for not upgrading to the latest version of WordPress is fear that their plugins won’t be compatible. As part of our continuing efforts to make WordPress core, plugin, and theme upgrades as painless as possible, Michael Adams developed and launched a beta of a new “Compatibility” feature in the plugin directory, powered by your votes. When viewing a plugin in the directory, select a WordPress version and a plugin version from the drop-downs. If there has been feedback about this WordPress / plugin version combination, we’ll show you what percentage of responses marked that combination as compatible vs how many marked it as incompatible.

If you log in, you’ll be able to help us gather this information! Just select a WordPress version / plugin version combination and click the “Works” or the “Broken” button. Please note that this shouldn’t be used to report minor issues with a plugin. You should mark a plugin as “Broken” only if its core functionality is truly broken when run on the specified WordPress version.

Right now we’re just in information gathering mode. So get out there and vote! Don’t just vote on broken plugins… cast a “Works” vote for every plugin that works on the version of WordPress you are using. This can help improve the signal-to-noise ratio in our data and prevent a few mistaken “Broken” votes from weighing too heavily.

For developers, we’re now including this data in our API. The plugin_information action now returns a “compatibility” member with the multidimensional array format:

array( {WP version} => array( {plugin version} => array( {% of reporters who say it works}, {# responses} ) ) )

If the API knows which version of WordPress you are using (for example, if you are making this query using the plugins_api() function from with WordPress), the API will only return compatibility information for your version of WordPress.

Eventually, we’d like to gather this compatibility feedback from within WordPress, allowing you to vote directly from your plugins admin screen. The ultimate goal is to use this information to inform you of plugin incompatibilities with a new version of WordPress during the upgrade process. For that to be useful we need a large set of high quality compatibility data. Start voting!

As you know over the past couple of months we have been working on the new features for WordPress 2.9. We have also been working on trying to make WordPress as secure as possible and during this process we have identified a number of security hardening changes that we thought were worth back-porting to the 2.8 branch so as to get these improvements out there and make all your sites as secure as possible.

The headline changes in this release are:

• A fix for the Trackback Denial-of-Service attack that is currently being seen.
• Removal of areas within the code where php code in variables was evaluated.
• Switched the file upload functionality to be whitelisted for all users including Admins.
• Retiring of the two importers of Tag data from old plugins.

We would recommend that all sites are upgraded to this new version of WordPress to ensure that you have the best available protection.

If you think your site may have been hit by one of the recent exploits and you would like to make sure that you have cleared out all traces of the exploit then we would recommend that you take a look at the WordPress Exploit Scanner.  This is a plugin which searches the files on your website, and the posts and comments tables of your database for anything suspicious. It also examines your list of active plugins for unusual filenames.  You can read more about this plugin here – “WordPress Exploit Scanner“

We have been hard at work now for a few months on the new features that will be coming in WordPress 2.9, and we are near the time when the first beta version will be available. We’ll need your help with beta testing the new features and ironing out any bugs.

There are a number of different ways in which you can get involved in the testing process, and each way is suited for each persons skill set and comfort level.  First of all, you can join the wp-testers mailing list to keep up to date with the testing progress and to discuss things with the other testers.  Secondly, you can head over to the Trac ticketing system and either create tickets for bugs you find or use some of the useful searches to look for patches that need testing or that need someone to try and reproduce the issue.

During the beta phase we are going to focus on stabilizing the new features and removing existing bugs which are well-understood and have easily testable solutions.  During this process we will not be adding any new enhancements so as to ensure that the focus is on making the 2.9 release as bug-free as possible.  We will also try and have a few special bug hunt days where one or more experienced WordPress developers will be available to help people track down issues and get patches committed to fix bugs.

To make is as easy as possible for you to get a beta testing install up and running we have put together a small WordPress plugin which makes it really easy to convert a test install of the latest release version of WordPress into a beta test install of the next up and coming release.  The plugin is called WordPress Beta Tester and is available to download from WordPress Extend or can be installed using the built-in plugin installer.  Please make sure you to only install this plugin on a test site. We do not recommend running beta versions on your normal, live sites in case anything goes wrong.  You can read more about the plugin in “Making it easy to be a WordPress Tester”

We are aiming to release the first beta version of 2.9 around the end of October, after we have put the finishing touches on the new features. Then we switch to full on beta testing mode and your help and feedback will be very much appreciated.  During the beta test program will push out new builds for automated upgrades regularly. Once we feel that a suitable level of stability has been achieved we will move into the release candidate phase. We hope to be able to make the final release 2.9 build available in either late November or early December.