#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.

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!

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.

Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts.

The tactics are new, but the strategy is not. Where this particular worm messes up is in the “clean up” phase: it doesn’t hide itself well and the blogger notices that all his links are broken, which causes him to dig deeper and notice the extent of the damage. Where worms of old would do childish things like defacing your site, the new ones are silent and invisible, so you only notice them when they screw up (as this one did) or your site gets removed from Google for having spam and malware on it.

I’m talking about this not to scare you, but to highlight that this is something that has happened before, and that will more than likely happen again.

A stitch in time saves nine. Upgrading is a known quantity of work, and one that the WordPress community has tried its darndest to make as easy as possible with one-click upgrades. Fixing a hacked blog, on the other hand, is quite hard. Upgrading is taking your vitamins; fixing a hack is open heart surgery. (This is true of cost, as well.)

2.8.4, the current version of WordPress, is immune to this worm. (So was the release before this one.) If you’ve been thinking about upgrading but haven’t gotten around to it yet, now would be a really good time. If you’ve already upgraded your blogs, maybe check out the blogs of your friends or that you read and see if they need any help. A stitch in time saves nine.

Whenever a worm makes the rounds, everyone becomes a security expert and peddles one of three types of advice: snake oil, Club solutions, or real solutions. Snake oil you’ll be able to spot right away because it’s easy. Hide the WordPress version, they say, and you’ll be fine. Uh, duh, the worm writers thought of that. Where their 1.0 might have checked for version numbers, 2.0 just tests capabilities, version number be damned.

The second type of advice is Club solutions; to illustrate, I’ll quote from Mark Pilgrim’s excellent essay on spam 7 years ago, before WordPress even existed:

The really interesting thing about these approaches, from a game theory perspective, is that they are all Club solutions, not Lojack solutions. There are two basic approaches to protecting your car from theft: The Club (or The Shield, or a car alarm, or something similar), and Lojack. The Club isn’t much protection against a thief who is determined to steal your car (it’s easy enough to drill the lock, or just cut the steering wheel and slide The Club off). But it is effective protection against a thief who wants to steal a car (not necessarily your car), because thieves are generally in a hurry and will go for the easiest target, the low-hanging fruit. The Club works as long as not everyone has it, since if everyone had it, thieves would have an equally difficult time stealing any car, their choice will be based on other factors, and your car is back to being as vulnerable as anyone else’s. The Club doesn’t deter theft, it only deflects it.

Club blog security solutions can be simple (like an .htaccess file) or incredibly complex (like two-factor authentication), and they can work, especially for known exploits. Club solutions can be useful, like using a strong or complex password for your login — no one would recommend against that. (Another club solution is switching to less-used software on the assumption or more like the software’s claim that it’s perfect and more secure. This is why BeOS is more secure than Linux, ahem.)

In the car world, if someone figured out how to teleport entire cars to chop shops, The Club wouldn’t be so useful anymore. Luckily for manufacturers of The Club, this hasn’t happened. Online and in the software world, though, the equivalent happens almost daily. There is only one real solution. The only thing that I can promise will keep your blog secure today and in the future is upgrading.

WordPress is a community of hundreds of people that read the code every day, audit it, update it, and care enough about keeping your blog safe that we do things like release updates weeks apart from each other even though it makes us look bad, because updating is going to keep your blog safe from the bad guys. I’m not clairvoyant and I can’t predict what schemes spammers, hackers, crackers, and tricksters will come up with with in the future to harm your blog, but I do know for certain that as long as WordPress is around we’ll do everything in our power to make sure the software is safe. We’ve already made upgrading core and plugins a one-click procedure. If we find something broken, we’ll release a fix. Please upgrade, it’s the only way we can help each other.

WordCamp New Zealand: Wellington, New Zealand, August 8-9, 2009

WordCamp Huntsville: Huntsville, Alabama, USA, August 15–16, 2009

WordCamp Los Angeles: Los Angeles, California, USA, September 12, 2009

WordCamp Philippines: Makati City, Philippines, September 19, 2009

WordCamp Portland: Portland, Oregon, USA, September 19-20, 2009 (Last year’s PDX WordCamp was awesome, IMO.)

WordCamp Seattle: Seattle, Washington, USA, September 26, 2009

WordCamp Birmingham: Birmingham, Alabama, USA, September 26-27, 2009

WordCamp Netherlands: Utrecht, Netherlands, October 31, 2009

WordCamp NYC: New York, New York, USA, November 14-15, 2009 (Logo contest in progress!)

WordCamp Mexico: Mexico City, Mexico, November 20, 2009

If any of these are within a reasonable distance to you, consider attending. WordCamps are a great way to meet other WordPress users, find collaborators, and expand your t-shirt collection*. I know I’ll be hitting at least a few of these; WordCamps are also a great way to get user feedback to take into consideration while we’re making decisions about what to include in core.

You can always find an up-to-date list of upcoming WordCamps at WordCamp Central. You can also try searching for WordPress groups at Meetup.com to find more regular monthly gatherings in your area.

*Most WordCamps include an event t-shirt in the registration fee.

Many of the security improvements to the new versions of WordPress in the last couple of years were complete reworks of how various systems were handled. Porting those changes to the 2.0.x branch would have been a monumental task and could have introduced instability or new bugs. We had to make hard decisions between stability and merging in the latest security enhancements. Additionally, far fewer people stayed on the 2.0.x branch than we anticipated. I take that as a testament to the new features in WordPress and perhaps even more the features offered by plugins, many of which don’t support older versions of WordPress!

I’m disappointed that we weren’t able to keep the branch maintained until 2010, but since one of the big reasons for that failure was the massive scope of our security improvements for the newer versions of WordPress, 2.0.x doesn’t die in vain!

These are the features that we’re asking people to vote on (in alphabetical, not prioritized, order):

Additional Media Filters: In the uploader, you can currently upload an image from your hard drive, link to an image from a URL, or select an image from the Media Library. This proposed feature would add links in the Media Library pane that would allow you to filter images to those that had been used most recently, used most often, and/or marked as a favorite. These filters would be available on the Media Library screen as well.

Basic Image Editing: Enable cropping, resizing and 90-degree rotation of uploaded images.

Better Media Settings: Enable the creation of more default media settings controlled in the Settings section, and allow settings to be overridden  during the individual media upload process as needed.

Bulk Media Import API: Develop an API to allow for bulk media importing by plugins or importers.

Custom Image Sizes: Instead of hardcoded thumbnail, medium, large, etc. image sizes, custom image sizes would allow you to configure the maximum dimensions for each of the sizes.

Easier Embeds: Make it easier to embed third-party content such as YouTube videos, etc. Similar to Viper’s Video Quicktags plugin.

Media Albums: Ability to create and edit photo albums that can stand alone (as opposed to galleries being tied only to a post), including photostream functionality.

Media Metadata: Enable the use of categories and tags on media files.

Photostream: Create a Flickr-style photostream that simply displays images in a chronological stream (as opposed to grouping in galleries).

Post thumbnails: Choose an image to appear as a thumbnail with your post/article/excerpt.

Revised Media UI: Redesign the uploader UI to make uploading and editing media files a simpler, more user-friendly process.

These descriptions are repeated in the beginning of the voting survey, so if you forget what something means you’ll be able to scroll up to remind yourself. Only the first question (pick your top choice) is mandatory. This survey isn’t very long. Question two lets you assign a general high/low priority to each of the 11 feature suggestions, while question 3 asks you to rank the 11 features in order of priority from 1-11. A text box or two allow you to make additional suggestions, and that’s it. The survey is anonymous, and will be open all week, until Friday, July 10, 2009 at 11:59 PM UTC.

No JavaScript? Take the survey here.

Results of the survey will be used to help developers decide which features to focus on for version 2.9. The 2.9 anticipated feature list will be posted here later in July, after the priority has been determined. How many contributing developers are available to code various features will play a large part in the decision-making process, so if you’ve ever thought of contributing code to WordPress development, now’s a great time to get involved. Developer chats are held each Wednesday in the IRC channel (irc.freenode.com #wordpress-dev) at 9 PM UTC (5pm Eastern, 2pm Pacific).

* – Other non-media features that were discussed either were determined to be better held for a future version for technical reasons, or were so widely desired that they were accepted for the 2.9 roadmap without requiring a vote.

• Certain themes were calling get_categories() in such a way that it would fail in 2.8. 2.8.1 works around this so these themes won’t have to change.
• Dashboard memory usage is reduced.  Some people were running out of memory when loading the dashboard, resulting in an incomplete page.
• The automatic upgrade no longer accidentally deletes files when cleaning up from a failed upgrade.
• A problem where the rich text editor wasn’t being loaded due to compression issues has been worked around.
• Extra security has been put in place to better protect you from plugins that do not do explicit permission checks.

If you would like to automatically upgrade from 2.8 to 2.8.1 Beta 1, follow these instructions.  Thanks for testing WordPress.

If you’re interested in what has changed since beta 2, consult the changelog.