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.
I read about the plugin issue on the testers mail list. Seems to me that the biggest problem with just de-activating a plugin that is not yet supported in a WP update is that if the plugin requires you to place a tag/function call on one of your templates then you will now suffer an unresolved call. I know I had to wait a week to update to 2.0 until a plugin I use was supported - or remove the call from my sidebar.
I am probably wishing in the wind, but rather than just de-activating plugins, it would be so muh sweeter to have a central repository of 'supported' plugins and prior to Wp upgrade the repository could be queried for plugins not yet new verion 'ready'.
To be honest, I have never understood why the f*** posting interfaces are different for pages and regular posts.
Here's how I envision this plugin thing would work, which should address all of your (andy) issues.
Plugins will have an additional field for holding an update URI. Only at two times will this URI be used: When upgrading, and when a "Find Updates" button is explicitly pushed on the plugin page.
The URI should point to a resource that responds to a basic REST request, returning pre-formatted XML data about what versions of the plugin works with what versions of WordPress. The core code would find the current version of the plugin in that data, and retreive the required WordPress version. The required WordPress version would be compared to the current WordPress version. (Note that during an upgrade, the destination version is always the current version.)
During an upgrade, plugins that fail the test are deactivated. When upgrading or clicking the "Find Updates" button, the plugin data from those URIs would be cached.
The cached data is compared to the installed plugins, and recommendations are made on the plugin page. Some options include "Compatible, but upgrade available", "Incompatible with current WordPress, no update is available", "Compatible and active", and the best one yet, "Current plugin is compatible, update exists for an upgraded WordPress version". In this way, you could know which plugins were compatible before you even downloaded the new version of WordPress.
Plugins that don't provide this header field are automatically incompatible with versions of WordPress 2.1 and beyond. Being incompatible does not imply that the plugin can't be activated, just that you will get an incompatibility warning when you try it.
How does this avoid trouble from deactivated plugins whose functions are used in a theme? It doesn't. However, you still have access to the admin pages, where you can re-activate or upgrade those plugins, knowing the risks. Alternatively, the admin panel will let you select a theme that does not use that plugin or edit the theme so that function is not used.
The primary benefit is that WordPress itself doesn't stop working.
I also envision a system that lets you push a button to download and install a plugin upgrade from the plugin's home site. But let's just try small steps at first.
Any talk of fixed re_write .htaccess rules yet? Before the WP developers start crashing around adding cool shit, perhaps they could fix the broken shit first?
That would really be cool.
Despite knowing that WordPress filtered out posts that were dated in the future, it never occurred to me that this would interfere with the caching mechanisms that WordPress uses. So... this was quite an interesting read :D Thanks Owen!
On the issue of the plugin system, would plugin developers be expected to maintain the REST XML data regarding whether or not their plugin will work with whichever version of WordPress? I think the answer is "yes", from what you've said. It would be useful if there was some method, within WordPress, to create the appropriate XML data for your newly written plugin. Of course, a seperate plugin could be used to create the XML.
I'm just thinking out loud really, great article :D
(By the way, I tried using coComment on your site, and it came up with a big fat error message saying that coComment isn't supported on this page!)
Yes, plugin developers would be required to maintain the XML that describes what version their plugins work with. However...
It should still be possible to store your plugins in the wp-plugins.org repository, in which case your XML file could be hosted there and optionally maintained by someone else with appropriate permissions to your plugin repository.
Also, if the system I described is put in place, then as part of the testing process it will be necessary to create test XML files. A tool will probably emerge for generating them easily. If so, RedAlt is a great place to host such a thing, and I might end up doing exactly that.
I'm not sure why coComment isn't working at my own site. I'll have to look into that. :-\
Oh, so that's why you idiots have been spamming me like crazy with messages to the hackers list that I inevitably ignore... Ah well, at least it was for a seemingly good cause. :)
According to the coComment folks, their code looks for a » in the site title. Those of us using other characters are currently SOL, 'though they're looking into expanding their algorithm.
They're very responsive on the support forums.
Thanks for update. I have always wanted a draft status for Pages along with Post. Though I was hoping it would be there in 2.0 I'll now wait till 2.0.1 :-)
And the plugins update feature would be great as well. Now the only issue would be those plugins which have been discontinued :-(
@ceejayoz: I've added a bit of funky javascript to my page that will hopefully fix the Cocomment issue. I make make a plugin of it very soon.
@aJ: Just to be clear, these chagnes are not in 2.0.1, which is alrady released, but in the next version of WordPress, which we're currently calling "2.1", but will probably end up being "2.5" or "X3" or something.
Thanks Owen for the roadmap on plugin deactivation. Sounds good. I don't think it will remove all the forum problems :) but it should go some way.
[...] It seems the brilliant minds behind the machina that is WP are hard at work on 2.1, and you can read asymptomatic’s take on the initial changes. Especially pay attention to the comments, and Owen’s discussion of plugins, and a plan to protect your blog on upgrades. I will be approaching Owen shortly to see if he’ll be interested in being the subject of the next interview, as he comes on Skippy’s recommendation. Plus, I’d like to know more about the bloggers/WordPress meetups he attends there in his neck of the woods. If there’s anyone else you’d be interested in hearing more from, hit me up on the contact form. [...]