Editorial Flow Update, 1/24
Kovshenin, Nacin and I chatted today in IRC 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 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 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 UI (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.
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-24&sort=asc#m539794
Pippin (mordauk) 7:50 pm on January 24, 2013 Permalink
2). This is something I have really wanted for a long time, excellent!
Cliff Seal 7:51 pm on January 24, 2013 Permalink
“What use cases do you have for the second, user-facing feature?”
One example would be updates to breaking news, especially inside a larger news organization where there’s a review process. As news becomes more real-time (for better or worse), the space between updating a single post and live blogging will become more populated.
Daniel Bachhuber 8:00 pm on January 24, 2013 Permalink
@Cliff How does the review process work now, and how would it ideally work?
Cliff Seal 1:18 pm on January 29, 2013 Permalink
Sorry I missed your question here. It’d seem the second feature would be the ideal way to handle it—instead of the post, as a whole, being set to ‘Pending Review’ (or whatnot) and staying private until a reviewer publishes, an already published post could stay that way while a revision itself could be set to ‘Pending Review’ and be updated at will.
Knut Sparhell 8:27 pm on January 24, 2013 Permalink
This ‘draft revision’ will be available for pages, too. I presume. For sites that need to update their more or less static content, this will provide a clean way to update, instead of creating a new page with a new permalink.
Daniel Bachhuber 9:09 pm on January 24, 2013 Permalink
Yep, all ‘public’ post types.
hereswhatidid 8:42 pm on January 24, 2013 Permalink
2) Use Case
Daniel Bachhuber 9:29 pm on January 24, 2013 Permalink
Just out of curiosity: how does each user sign off on the content?
hereswhatidid 9:35 pm on January 24, 2013 Permalink
Currently the review approval is handled via email and the changes are posted to staging environment for review. Once they are approved, the site admin goes in and publishes the update. But, just having the ability to show a preview version on the live site would cut out the need for the staging site entirely which would be a big improvement.
I’m not sure having a system that would actually be able to deploy content only after specific users/groups have approved the content would be worthwhile to implement in the core. That would most likely still fall into the realm of a plugin. Just having the ability to save a Revised Draft which can be previewed would be something useful across the board.
krogsgard 9:58 pm on January 24, 2013 Permalink
Permissions for publish_revisions and edit_post/page_revisions vs publish_posts/pages and edit_posts/pages could take care of this. Let plugins / devs / members plugin take care of roles, other than defaults for editor / author, etc.
Triggering an email for when a revision gets sent to a pending status to the published post author would be awesome too.
Konstantin Kovshenin 7:38 am on January 25, 2013 Permalink
I worked with a few companies before where “bosses” were very sensitive about what information goes out there, so they had to sign off each piece. It was easy with posts and drafts, but published pages for sections like “our mission”, “about the company”, etc was a huge pain, because changes went in Microsoft Word first, signed off and then copy-pasted into WordPress.
Also, contributors wanting to make changes to their published posts is another obvious one.
Simon Dickson 10:42 am on January 25, 2013 Permalink
Use case for no2: we’ll still need to keep the option to edit the ‘live’ post, even if there is a revision in draft.
You can imagine: you might be mid-way through a substantial edit of a published post, or maybe you’re awaiting approval from someone. You suddenly realise there’s a factual error in the already published version. You aren’t ready to publish the new version in its entirety, but you can’t leave the error on the live site.
We’re almost talking about Git-style branching, in effect – a ‘master’ version (live), and a ‘development’ version (revision in draft). Maybe there’s a UI lesson there?
Daniel Bachhuber 1:15 pm on January 25, 2013 Permalink
How would you implement the ability to edit two versions of the same post at the same time?
Ben Huson 10:57 am on January 25, 2013 Permalink
“What use cases do you have for the second, user-facing feature?”
Use cases I can think of or have experience of are:
1. Updating page content to reflect a season change – ie new products etc
2. Updating pages to reflect a company change on a specific date – ie acquisition, annual report etc
I’ve used some bespoke CMS systems where a draft is created whenever you edit a published page and then you choose to save (as a draft), publish or schedule.
Would you be able to Schedule a draft revision as that would be very useful?
I feel that a content approval workflow would be best handled by a plugin.
Daniel Bachhuber 1:17 pm on January 25, 2013 Permalink
Scheduling a draft revision might be a possibility, and a nice added touch. We’ll explore that when we get there.
Ryan McCue 11:19 am on January 25, 2013 Permalink
One place where I’ve seen this sort of thing is with MediaWiki with extensions: http://www.mediawiki.org/wiki/Extension:Approved_Revs or http://www.mediawiki.org/wiki/Extension:FlaggedRevs
It looks those have an “approve” button next to revisions newer than the current published one, which I think could work. Perhaps if we add a new side metabox that lists revisions newer than the last published revision with approval and diff links.
(Ideally, the way this would work is that posts would be mere pointers to a revision, and publishing would bump the post pointer to the latest revision. This is similar to git branches, where “master” e.g. is just a pointer to a specific commit, and committing to that branch makes a new commit and then bumps the branch. For WordPress, we could do similar but basically make the approve button sync the post to the revision.)
Daniel Bachhuber 1:14 pm on January 25, 2013 Permalink
We discussed this some in IRC, and I’d be willing to have the conversation again, but I think the Git style approach is a little too complex and still plugin territory.
In particular, it seems like most of the named use cases don’t require this degree of complexity.
cvernon 3:43 pm on January 25, 2013 Permalink
Use case for 2) involves what is currently [imho] a bug: when you edit images, featured or attachments, custom fields or any other changes that are made at the db level through ajax to the original post, they are reflected on the front end immediately, without even needing to hit Update.
One thing we did in a custom CMS platform a few years ago to avoid this is that all editing is actually done to a copy of the post, and then when saving the copy is saved back to the original. I would strongly suggest we take advantage of this new feature to fix this current bug. Then, if you change images or custom fields, and then abandon the edit, we just throw away the duplicated ‘draft’ post + meta + attachments. This means a major rework because when deleting images from a post, the deleted images must be a copy so that they are not lost if we decide to stop editing or not go through with the changes.
Hope this helps.
sourceforge 4:21 pm on January 25, 2013 Permalink
thank you @daniel and @nacin, daniel @ vip and nacin @ wporg have been pulling things, thanks for the help!
Jeremy Felt 3:21 am on January 26, 2013 Permalink
I haven’t seen this exactly expressed yet, so tossing it out there. More conceptual, but also related to dealing with the current status stuff in core.
It seems that the current core post statuses (draft, pending, publish, future, private, trash) are pretty good indicators of a post’s current state in the system.
Most (all?) of the use cases for custom post statuses appear to fit under the umbrella of one of these post states, though with nomenclature that describes different parts of a custom worlkflow.
Would it be plausible to introduce the idea of attaching a post state to a post status when it is registered? This could allow current parts of core relying on these states to stay useful – though status/state naming is confusing – while also accounting for new workflows.
It would also be nice to see the ability for multiple post statuses to be assigned at once, which a structure based around states should allow for.
Daniel Bachhuber 5:44 pm on January 27, 2013 Permalink
Correct me if I’m wrong, but I believe what you’re talking about is actually something Nacin and I discussed on 1/18: abstraction of post status special capabilities. For instance, ‘future’ has a special capability of transitioning between two statuses at a specific point in the future.
We made the determination that the idea needs fleshing out conceptually before we can dive into it practically, so that type of enhancement is now out of scope for 3.6
This is probably outside the scope of any enhancements at this point.
Patrick Daly 3:28 pm on January 28, 2013 Permalink
While not my CMS of choice, Sitecore has a very robust workflow system. Rather than write all out here you might want to review everything they have: http://sdn.sitecore.net/upload/sitecore6/workflowreference-usletter.pdf
Daniel Bachhuber 12:08 am on January 29, 2013 Permalink
Thanks for sharing, Patrick. I’ll check it out.