owen

Whew.

There has been a lot of turmoil on the WordPress hacker mailing list about features for the next version of WordPress. If you didn’t get your chance to join the fun, you might want to read up on the craziness that people have suggested for improving WordPress before you start shooting off suggestions.

Today marks the first commit of the big new features, and it’s a doozy. I say “doozy” not because it’s a fantastic feature (oh, but it is), but because it’s a big change. I’ll explain it a little and maybe you’ll see why it’s so cool.

But you should know now, if this affects you - You might want to stop updating your site from SVN for a little while. Of course, if you do this via script, it might already be too late. Eek.

In WordPress 2.0.1, Posts and Pages are stored in the same table. This doesn’t change with the latest code update, however the method for marking a database row as Post or Page has changed. Instead of one field to demark a row as one of “Published Post”, “Draft Post”, “Private Post”, or “Page”, we’re getting two fields.

One field (type) says “This row is a Post/Page.” The other field (status) says, “This row is a draft/private/published.” What’s the big deal? Well, Pages can now be in draft, and possibly even private.

Of course, this may not mean must to you if you don’t have multiple authors or have a general need for draft status on your Pages. But if things go right, we may also get a new status setting, “future”, which means that the post (or page!) is scheduled to be published in the future. This is a pretty big deal, because the main post query is a tad inefficient when selecting records with dates.

In the current version of WordPress, the main post query uses a date in the WHERE clause to limit the posts it will return to only those posts that were published prior to the current time. That sounds fine, but it doesn’t allow caching tools for MySQL to do their jobs, since the query changes every time the time changes. If we knew in advance to eliminate an entire “type” of post from that query, the query would speed up significantly, potentially due to two things: Using a query cache would be more possible, and there would be no relative compare against a date, but a direct compare against a preset value.

All of this technical babble boils down to better performance. And everyone loves better performance.

This new changeset is just one of the big changes people on the hackers list have been plotting for WordPress. Primarily the discussion has focused on ideas that make WordPress easier to use, faster and more reliable, and less likely to generate support requests. What actual new functionality will appear in the next version remains to be seen.

One thing of keen interest to me is the recent topic of including a Firefox-like plugin update system. One of the big issues for 2.0 upgrades was seen by people who left plugins installed from their 1.5 installation when upgrading. If the plugin was incompatible, it was typical to see a white screen or some unhelpful errors, and there was no useful information about how to fix it. The next version of WordPress should include (if we follow through with what is currently being planned on the mailing list) a method to eliminate that issue. How exciting!

I can’t wait to see what other stuff is planned for the next version.