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 APIAPI 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. for registering new post statuses.

There’s an existing patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. in #12706 which solves some, but not all of the problems, which is probably why it’s been punted releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. UIUI User interface?
  • 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