I caught the post by Ryan via the WordPress Dashboard (I suppose that if I was still hooked into the WP mailing lists I would already have known about this) about SVN commits for version 1.6. I should de-geekify: The developers of WordPress have submitted some changes to the WordPress code repository for the next version of WordPress.
I want to make clear right here two very important things:
First - You should not use this code. It is not finished, and it probably doesn’t work. It will certainly make going back to version 1.5 impossible, and break your web site. Stay away.
If anything, you should use this review as an excuse not to try installing 1.6. Look at the pretty pictures, read the details, comment on the features, and wait.
Second - The features described here do not constitute final features in their full functionality. New features may be added. Features I describe may be removed before final release. Then again, you may get exactly what you see.
A couple of less important things to note: I did not fully test any of this. What you are about to read is the result of about 30 minutes of tinkering and reviewing code differences. You should probably look at the 1.6 Features on Codex for more information about what’s going on. Considering the scale of proposed changes, I don’t expect this version number to be the version number on the release, but that’s conjecture, as is most of what I write here, including this.
Now, on to the good stuff.
There are two large things that are immediately obvious to me while looking at the code and the output of the 1.6 codeset. The Write page has changed and the stored user data is changed. Let’s cover the Write page first.
In WordPress 1.5, the Write Post interface provides two views: Simple and Advanced. One nagging concern to me while writing code for WordPress is having to account for these two separate pages. This is not a problem in 1.6.
WordPress 1.6 eliminates the duality of complexity levels. All of the options are available on one page. The options that in 1.5 were classified as “advanced” are now tucked away in little collapsable panels. You can see in the animated graphic here how the panels not only expand and contract, but can be rearranged in position. The settings of the panels - expansion and position - are saved between page loads, so the next time you use the Write Post page, they appear the same as when you last left them.
At the bottom of the page, there is the usual “Advanced” area, with expandable and repositionable areas for the excerpt, custom fields, and trackbacks. The delete button for an existing post is in this area, but is not expandable.
For plugin developers, the old “edit_form_advanced” plugin hook is still there, but seeing as edit-form.php is now only called for the bookmarklet code in 1.6, the “simple_edit_form” hook is going to need to move. Also, there is currently no easy way via plugin to add new expando areas to the form in either the side location or in the advanced area. It would not surprise me to see these hooks added before release.
As of this writing, the CSS that positions user interface elements on the Write Page page has been removed, presumably because it was the same as that used on the Write Post page. None of the “advanced” options have been relocated, but this CSS change hints at an overhaul on the Write Page page, too.
The very first plugin I foresee being written to adjust this layout is one that lets you turn off the display of certain expando sections entirely. For example, I don’t use password protected posts on this site - I should never see that box. A simple UI elsewhere on the page that toggled the visibility of these items entirely would be very handy. This level of option is something that the WordPress developers have expressed disinterest in previously, so I suspect that a plugin will need to fill this need. But we’ll see.
The other big change is with the user data. This isn’t going to be as apparent to typical WordPress users as it will be to people who want to integrate advanced user features.
In WordPress 1.5 user information is stored in a single table. A separate field exists in that table for housing data about email, profile, and several instant messenger addresses.
In the new 1.6 schema, this data is going to be stored in a new table, “usermeta”. The usermeta table is structured the same as the postmeta table, which allows custominformation to be stored with each post. In this way, custom information can be stored with each user.
The current 1.6 code pushes and pulls data from the usermeta table. The user editing pages use the usermeta table for displaying and editing fields, but they look identical to the 1.5 version. I expect that may change before release.
I can only guess at what the developers have in mind for the use of this feature. All of the functions that request data from the usermeta table are pluggable, and can be replaced by custom functions. This is useful if you are using a plugin that allows authentication against a separate database. A grand example might allow an admin to set up a WordPress instance for users of some other web-based product, and tie their login information to that product’s central database. WordPress (using a plugin) could pull any metadata that the central database allows and offer it for publication via the user profile functions.
The metadata itself could be used for a variety of purposes. A plugin that sends email to site subscribers could store a usermeta flag for each subscribed user, then easily query the database for all subscribers and their email addresses, as listed in their WordPress profiles.
A more useful purpose for this new metadata would be to scrap the user level system for a more granular permissions-based approach to security. A “_permissions” key in the usermeta table (not displayed directly in any interface by implication of the prefixed underscore) could contain an array of text-based flags that enable certain WordPress features for that user. The array could contain flags for “can_write_posts” or “can_edit_posts” for example. This would allow admins to assign specific-purpose permissions to individual users without giving away the farm. The user editing page would provide a checklist of these options for the user that could be toggled. A simple plugin hook could allow plugins to add new options to this list for display. A plugin so-inclined could provide additional functionality to permit or deny individual user permission for writing and/or editing within certain categories. It might also be handy to allow presets for these permissions based on the WordPress 1.5 numeric user levels.
There have been some changes to the feeds, too. All four feed types that WordPress offers (RDF, RSS, RSS2, Atom) have had two or three new hooks applied to them. The first executes in the namespace area of the feed. The second executes after the basic channel information (such as where the title of the feed is defined) before any feed items. The third executes inside each feed item after the existing item content. Plain RSS .92 does not use namespaces, so it does not have a namespace hook.
These hooks could be used to add additional feed information to feeds. These hooks would not be used to, for example, add advertising to a feed, which should be done using the feed content filters, like “the_content_rss”.
Of possible interest to developers, the wp-blog-header.php contents have been spread around into separate files. A new class, WP, contains much of the original functionality, but a file, template-loader.php, now contains the big switch for loading appropriate templates. The WP class nicely organizes the code into discrete function calls, which makes reading the intention of the code a little easier to follow, even if the functions are spread out into more complicated locations.
If you’re perusing the code, I suggest a good editor with find-in-files features, so you can search for “function X(” and get faster results.
That’s it for my code review today. If I learn of any more major updates that seem intersting enough to share, I’ll post screenshots or change notes. Feel free to comment on the features you have read about here.
