Kovshenin, Nacin and I chatted today in IRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. about scope for editorial flow in 3.6. To help narrow things down, we’re now focusing on two things:
1) “Finishing” the existing API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. such that you can register new post statuses with expected results (no bugs, etc.).
Last week, Nacin and I had a long conversation about how enhancing the post status API in various ways could lead to complex, fully-featured workflows. We discussed again yesterday after the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. IRC chat, and decided these enhancements still need more conceptual development. Instead, we’ll be focusing on the extent of #12706‘s description:
A developer should be able to register a custom post status using register_post_status(). The admin (and super admin) UI User interface (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to ‘draft’ and ‘pending’ statuses in core that should properly use the post status API.
All existing arguments to register_post_status() should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.
I hope to have a working, testable implementation of this by next week, using existing patches and maybe some new code.
2) Allowing already published posts to be revised without being updated immediately.
We discussed a few possible implementations of this. Our conclusion is to go with the simplest possible implementation, as there are already a few plugins to handle more complex implementations.
Right now, it’s looking like this: a ‘draft revision’ can be created of an already published post. If a ‘draft revision’ of a post exists, it will appear in the post editor (instead of the published content). Anyone with appropriate permissions can make edits to the ‘draft revision’ without having those changes go live. Then, at some future point, the ‘draft revision’ can be pushed live to take the place of the original published post.
Kovshenin will be working on wireframes for this over the weekend.
We want your help!
- What use cases do you have for the second, user-facing feature? The more details you can provide, the better.
- Have you come across software which does the second piece well? Notably, it would let users easily choose between pushing their update live immediately, or continuing to work on and save their changes as draft.
The next office hours will be Tuesday, January 22nd at 10 am PT / 1 pm ET / 1800 UTC.