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 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 patch 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 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. UI 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:
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 Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. 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.
#3-6, #editorial-flow