Ryan on WordPress

As has been mentioned elsewhere, WordPress 2.0 is in beta. We’ve kept it low key so far, but we’re getting a pretty good testing turn out nonetheless. Several little bugs have been shaken out since the first beta. If you are feeling adventurous, try it and share your beta experience in the Beta Forum or on the Testers List. As always with unreleased versions, don’t use it on your live site just yet. If you do, make a backup and be ready to rollback.

To keep track of bug fixes going into 2.0, watch the timeline. We’re fixing bugs pretty briskly and releasing new 2.0 release candidates as we go.

One of the big recent additions is the Persistent Object Cache. Objects such as pages, categories, options, and users are saved locally to disk so that WP doesn’t have to make a trip to the database. The object cache is completely pluggable, allowing hosts to tailor the cache to their particular usage and needs. Folks on the hackers and testers lists have been shaking out the bugs. The cache is looking pretty stable as of now.

I gave a little love to wp-mail. If you use wp-mail, give it a try in the recent nightlies.

Thanks to Owen, we now use the entire category hierarchy when resolving category URIs. Previously, subcategories with the same name but different parents were not addressable. This bug has been around for awhile, and I’m glad to finally be rid of it. Now we need to do the same thing for pages.

What with all of the backend admin changes that have gone in, the bookmarklet was horribly broken. It is operational once again. It still needs some UI love, but it works.

We recently added database versioning. Until now, the database was unversioned. When running upgrade.php, we would do all of the steps necessary to upgrade the DB from the earliest release of WP to the latest, regardless of what release of WP generated the DB being upgraded. To accomplish this, the upgrade code had to ensure that every action it performed worked against all versions of the WP DB and produced the same results no matter how many times upgrade.php was called. This could be a pain since we had to ensure that every upgrade action could recognize and not step on its own work when being called for the second, third, and fourth times. With the addition of a database version, we can do the work once and skip it on subsequent calls to upgrade.php. This makes the upgrade code easier to write and makes upgrade.php run faster. For example, 1.2 had some problems with double slashing quotes. Code in the upgrade went through the entire DB and fixed these double slashed quotes. This is an expensive operation that was run every time upgrade.php was called, even when upgrading from later releases that did not have the problem. Now we check the database version and skip that step if we aren’t upgrading from a 1.2 or earlier database. If you run upgrade.php against an up-to-date DB, upgrade simply returns immediately and does not touch the DB. A simple change that was overdue.