Updates from December, 2012 Toggle Comment Threads | Keyboard Shortcuts
Version 0.7 is tagged and I am planning to submit it to the WordPress.org plugin directory later today or tomorrow.
Viewing code revisions now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).
Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHP 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..
In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.
(During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)
The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.
At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.
So when we talk about term meta, we’re actually talking about term taxonomy meta – meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.
(There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)
At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.
It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the
wp_termstable. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.
These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.
Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical on every install. If we moved the slug and name fields from
wp_term_taxonomy, we could actually drop
How can we remove an entire table but still be backwards compatible? We came up with two solutions:
- Because all fields in
wp_termswill exist in
wp_termscan be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
- Because all fields in
wp_termswill exist in
wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables,
$wpdb->termscan simply be set to
$wpdb->term_taxonomy. A query that previously joined
wp_term_taxonomywould just join itself.
In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a
wp_termstable. Wow, right?
So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new
WP_Termobject to model
WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.
Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))
Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.
The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current
wp_term_relationshipstable to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).
A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects. It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)
That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.
- Because all fields in
I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.
Things this will likely involve:
- Local storage of post data while editing, in-between autosaves and manual saves.
- More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
- Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
- Probably some interaction with the team working on improving Post Revisions.
- UX work for making recovery from failure scenarios smooth, clear, and worry-free.
Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.
We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.
Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.
Antsy for 3.6 to start and need a project? Who wants to make an official importer for the new Twitter archives? Would think we’ll want to add that into the importers list. Would suggest importer auto-assign “status” or “aside” post format (or make it an option in the plugin to choose format). Who’s in? I volunteer to ux review and test.