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:

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-18&sort=asc#m535910

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:

https://docs.google.com/spreadsheet/ccc?key=0An-ruHGRV0xZdG1SOWJZcW9ORjlrNFZYY0VkQTBmYUE

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.