Editorial Flow Update, 2/7

Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow

Editorial Flow Update, 1/31

Kovshenin and I held office hours today but we didn’t discuss too much. Both of us have a pretty good understanding of what work needs to be done — we just need to do it.

One thing that’s come up is that #20299 (Preview changes on a published post makes all post meta “live”) is a blocker for editing already published posts. So we’ll have to figure out what we’re going to do for that.

I’d like for us to have demoable code by the next office hours: Tuesday, February 5th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow

Editorial Flow office hours today Tuesday at 1800…

Editorial Flow office hours, today (Tuesday) at 1800 UTC.

I’ve been working on some mockups over the weekend of possible UI implementations for revising published content. Still very draft and a bunch of unanswered questions, nonetheless here are some pictures:

  • The “Save as Draft” and “Publish Changes” flow: http://cl.ly/image/1b401P3B0d3U
  • “Update” vs “Save as Draft” with a drop-down button: http://cl.ly/image/2o0C3b3r252d
  • “Save Changes for Later” vs “Discard” in a drop-down button: http://cl.ly/image/0y0T0Y0H0M1X
  • Everything hidden in a misc-publishing-action: http://cl.ly/image/2J0e0A3N0F2b
  • What a contributor would see: http://cl.ly/image/1Q2V1Q3L3L46

So the agenda for today’s office hours is to discuss these, and maybe pick a direction (even if it’s totally different from the list above). Since there’s an overlap with the Revisions team, would appreciate if @westi and/or @ethitter popped in.

#3-6, #editorial-flow

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.


#3-6, #editorial-flow

Editorial Flow Update, 1/18

Nacin and I chatted today about what we want to do about editorial flow in 3.6. At the crux of building any new features is completing the API for registering new post statuses.

There’s an existing patch in #12706 which solves some, but not all of the problems, which is probably why it’s been punted release after release. The problems can be understood as the following questions:

  • How are custom statuses related to post types? Are they global? Can they be assigned to only some types? Can they have different properties for different types?
  • How can we describe transitions from one status to another? How does the current status (and the state of the post in general) inform which statuses are available? How are capabilities used to affect which statuses are available? How do we describe the ability to access or affect a post based on its current status?
  • How do custom statuses factor into core UI?
  • How do we define and/or extract the special features of existing core statuses?

The most substantial question is the last one. It’s worth reading through the chatlog in understanding how we got there as there’s a fair amount of exploratory thinking:


The primary project right now is tracking down each of those special use cases. You can help out!

A “special use case” is a particular way the status (or statuses) manifests itself in core behavior. For instance, ‘draft’ and ‘pending’ appearing in a dropdown when editing an individual post is one manifestation of a special use case. When identifying these special use cases, please point to all relevant lines of code and indicate the core statuses affected.

Here’s the Google spreadsheet:


The secondary project right now is identifying use cases for custom post statuses. For example, as Nacin and I got to in the chat, Edit Flow’s custom status support is used for essentially creating new, labeled versions of the ‘draft’ status; essentially, establishing a workflow before publication:

pitch -> assigned -> in-progress -> ready-edit

If you were building a ticketing system on WordPress, however, you might have all public statuses like this:

new -> assigned -> resolved -> verified -> closed -> rejected

It would be tremendously valuable to have a variety of established use cases to play with once we start poking at the API. The more details for each use case the better.

The next office hours will be Tuesday, January 22nd at 11 am PT / 2 pm ET / 1900 GMT.

#3-6, #editorial-flow

WordPress 3.6: Editorial Flow

I’m really excited to see our editorial flow get some love in the 3.6 cycle! We always want to be as extensible as possible and post statuses are one of those places where we’re not near as good as we should be. The plan goes something like this:

  1. Fully support the existing register_post_status() API in core
    • Make sure things don’t break when you add your own custom statuses
    • Update the metabox UI to show any newly registered statuses in the drop down, etc.
    • Add a ‘moderation’ flag so that unpublished statuses can be explicitly identified
    • Support for non-standard public post statuses
  2. Enhance the existing API
    • Add support for registering post statuses to specific post types
    • Allow for caps checks on different post statuses
    • New remove_post_status() function for removing an already-registered post status
  3. Editing workflow for already published content

Additionally, we hope to address some issues around post meta for revisions, which is tightly related to the workflow for already published content.

@markjaquith and I have chosen Daniel Bachhuber to lead this. If you’re not sure why, just Google WordPress Edit Flow and it’ll all make sense. There’s a lot of heavy-duty under the hood work here, so please leave a comment if you’re interested in lending a hand.

#3-6, #editorial-flow