Custom post status bugs

[ptahdunbar]

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.

Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status).

[ptahdunbar]

Related: #12567

[ptahdunbar]

Don't have time for this so I'm pushing it back for 3.1 unless someone can tackle it :)

[nacin]

I don't see this as a bug. We simply never completed the API here.

Very similar to how we started custom post types in 2.9 then went through it with 3.1.

Moving to enhancement... Will probably end up as a task though.

[johnkolbert]

Related and in progress: ​http://core.trac.wordpress.org/ticket/12567

[johnkolbert]

Just to let those know who are following this ticket, I just updated the diff file to this related trac ticket (​http://core.trac.wordpress.org/ticket/12567) and would enjoy any feed back.

[nacin]

Someone is free to start working on this before I get to it.

I want post statuses to be registered to a post type. That's one thing that gets me.

We also have like 18 properties but still need more based on things I noticed when trying to utilize what was there. So we should figure out a way to properly handle everything.

[andreasnrb]

Think we need to do a write up of what the different options actually do.
Supposed difference between public, private, protected. _builtin and internal etc.
Public,private,protected makes custom post type with that status show up on its listings page.

The All(x) link always show the total count for the post type even with a unregistered post_status but the page display No post types found.

[nacin]

#14318 was previously closed as a duplicate.

[ptahdunbar]

Alright, let's get this ticket moving. There's a few args in the current version of register_post_status that either make no sense, are redundant, or ones that I just don't understand and could use some clarification.

Here's the new params for the register function:

register_post_status( $post_status, $post_type, $args = array() );

Parameters:

• $post_status (string) - Name of the post status.
• $post_type (mixed) - string or array of post types to assign to the post status.
• $args (array) - Optional.

Public args:

• label - A descriptive name for the post status. Defaults to $post_status
• label_count - Label used in the admin status links to display the post status' singular/plural count label. Defaults to label
• post_type - An array containing post types this post status is associated with. Defaults to 'any'.
• exclude_from_search - Whether to exclude posts with this post status from search results. Defaults to null.
• public - Whether posts of this type should be shown in the admin UI. Defaults to null.
• internal - Whether the post status is internal. Removes from any ui/query listing.
• protected - User must have edit permissions on the draft to preview. Defaults to null.
• private - Limited to viewing by the author of a post or someone who has caps to read private states. Defaults to null.
• publicly_queryable - Whether post status queries can be performed from the front page. Defaults to null.
• show_ui - Whether to show the post status in the admin UI. Defaults to null.
• edit_cap: changing the post status can be limited by capability. If set, users must have the declared capability to change change posts to this post status. Defaults to null.

Internal args: (Used by WP core built-in post statuses)

• _builtin - If this post status is a native or "built-in".

Args I left out: (can anyone explain the need for these?)

• show_in_admin_all
• show_in_admin_status_list
• show_in_admin_all_list (uses show_ui instead)
• single_view_cap
• capability_type
• hierarchical
• _edit_link

Functions that (most likely) need updates:

• get_available_post_statuses
• wp_edit_posts_query
• get_post_statuses
• get_page_statuses
• post_submit_meta_box

Files that need updates

• edit.php:261
• export.php:55,:132 (do we need a can_export arg?)
• query.php:2234
• script-loader.php & post.dev.js

See #12567

Thoughts?

[wpmuguru]

There shouldn't be a separate function for page statuses. Pages are now just another post type other than WordPress needs to support features from when they were distinct.

The post type already has a can_export flag. The post status should depend on the post type flag for this. Though, this raises the issue of conditionally showing the post status on the export screen when it only applies to specific post types.

[nacin]

get_page_statuses() is for back compat. I think get_page_statuses() and get_post_statuses() are only used in XML-RPC. They have hard-coded stati for that reason.

[kevinB]

Can we please default post_type to null? This is the standard approach for everything except the query variable, making

! empty ($status_obj->post_type)

sufficient to detect post_type customization in 3.0 and 3.1+

[ptahdunbar]

Replying to kevinB:

Can we please default post_type to null? This is the standard approach for everything except the query variable, making

! empty ($status_obj->post_type)

sufficient to detect post_type customization in 3.0 and 3.1+

The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.

[kevinB]

Replying to ptahdunbar:

Replying to kevinB:

Can we please default post_type to null? This is the standard approach for everything except the query variable, making

! empty ($status_obj->post_type)

sufficient to detect post_type customization in 3.0 and 3.1+

The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.

That breaks the API for plugins and themes which were written for WP 3.0. Why not make post_type part of the args array? Then calling code can associate the status with all post types if the property is defaulted null or not set.

[kevinB]

Replying to kevinB:

Replying to ptahdunbar:

The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.

That breaks the API for plugins and themes which were written for WP 3.0. Why not make post_type part of the args array? Then calling code can associate the status with all post types if the property is defaulted null or not set.

By calling code, I mean consumers of the resulting status object.

[kevinB]

plugin to demonstrate custom stati "Approved" and "Secret". Corresponding roles of "Reviewer" and "Super Editor"

[kevinB]

Just uploaded a ​patch for the first issue. This is mostly comprehensive, supporting use of the following type of stati:

• private type, indicated by $status_obj->private. Some functionality as normal private, but a separate set of capability requirements which may include all or some of the following: "read_secret_posts", "edit_secret_posts", "delete_secret_posts", "set_secret_posts" (the "publish" equivalent). If a status-specific caps is not defined for some operation, the normal private status equivalent is used.

• pending type, indicated by $status_obj->moderation. Enables additional multi-step moderation, optionally with status-specific capabilities. A new filter is applied to allow plugins to customize the default moderation status for the main Submit button:

$moderation_status = apply_filters( 'post_moderation_status', 'pending', $post->ID );

Remaining Issues:

• I didn't touch xml-rpc or map_meta_cap (but see meta mapping in attached plugin for ideas)

• Custom public stati now have some backend support but no Edit Form UI integration. The complication-to-benefit ratio seems much higher here; at this point I'm not eager to push it.

• The js I moved into edit-form-advanced.php should be reviewed for optimal delivery method.

• I don't know the WP way to compress js files. post.js and inline-edit-post.js in this patch are a copy of uncompressed dev.js

Demo Plugin:
I also attached a ​plugin to demonstrate two custom stati via the following roles:

• "Reviewer" - has edit_approved, delete_approved, set_approved, edit_others, delete_others for all post types

• "Super Editor" (name='super') - has read_secret, edit_secret, delete_secret, set_secret for all post types (in addition to regular editor caps)

The WP roles definitions will be added to your DB, but db-stored capabilities are only that of Contributor and Editor, respectively.

[kevinB]

For the second issue (statuses should be registered to one or more post types), I suggest following the pattern set for taxonomies:

function register_taxonomy_for_object_type( $taxonomy, $object_type) {
	global $wp_taxonomies;

	if ( !isset($wp_taxonomies[$taxonomy]) )
		return false;

	if ( ! get_post_type_object($object_type) )
		return false;

	$wp_taxonomies[$taxonomy]->object_type[] = $object_type;

	return true;
}

I would be able to implement that type of solution early next week if nobody else has it done by then.

[nacin]

Hi kevinB, for compressed scripts, only edit the .dev.js versions, and omit the compressed versions. We will then handle compression on commit.

I've asked Ptah to review this patch as I know he is also working on a patch, so let's see what we can grab from each to continue.

[ptahdunbar]

I'm thinking we should group the arguments into patches instead of writing up one big diff.

register_post_status() needs a labels arg for all of these:

• name
• count
• caption
• published (maybe a better wording?)
• save_as (maybe a better wording?)

For the post_type arg, we need to be loop through the post_type arg and register_post_status_for_type()

• post_type

There also needs to be a new post_status arg in register_post_type() that calls register_post_status_for_type(). If the post_status arg isn't passed, it registers all the builtin post statuses to that post type.

We'll need a post_type_has_status() (similar to what johnkolbert wrote in #12567) and use that throughout post_submit_meta_box() to turn features on/off.

I'm not exactly 100% sure on how public, private, and protected work in terms of what functionality they add outside of what's in the post_submit_meta_box() metabox.

• public
• private
• protected
• internal

And finally post status capability. Can anyone elaborate how this should work?

[kevinB]

Replying to ptahdunbar:

I'm not exactly 100% sure on how public, private, and protected work in terms of what functionality they add outside of what's in the post_submit_meta_box() metabox.

• public
• private
• protected
• internal

public stati are published and readable by default to all logged and anonyomous users (an abstraction of the "publish" status).

private stati are published but readable based on possession of the appropriate capability (an abstraction of the "private" status).

protected means a status is not currently readable to any user on the front end, except for previews.

internal means never readable on the front end, post are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)

My patch includes another proposed status type:
moderation means a status is part of an editorial moderation process. Not readable on the front end, except for previews (an abstraction of the "pending" status).

---

And finally post status capability. Can anyone elaborate how this should work?

If the existing pattern is followed, capabilities for custom stati would be specified by setting

$type_object->cap->edit_{$status}_posts = ...
$type_object->cap->delete_{$status}_posts = ...

... and if the status is of private type:

$type_object->cap->read_{$status}_posts = ...

In addition, there is a need for a "publish" capability specific to custom public, private and moderation stati:

$type_object->cap->set_{$status}_posts = ...

If there is sentiment for a different model such that $type_obj->status_cap is a status-keyed array property, now is the time. Thoughts?

[kevinB]

correction...

Replying to kevinB:

protected means a status is not currently readable to any user on the front end, except for previews.

internal means never readable on the front end, post are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)

protected means not readable to any user on the front end, except for previews.

internal means not readable on the front end, posts are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)

[kevinB]

The updated ​patch also fixes some core bugs which may deserve their own ticket. I included them as part of this patch because my overall custom stati solution depends on the fix, or vice versa:

• wp_list_filter() : 'or' argument does not work, always returns all members. This function is called by get_post_stati(), get_post_types() and get_taxonomies()

• Users lacking publish capability can change an existing post of any status to Privately Published status via Quick Edit

• On visibility or publish date change, js recaptions publish button as "Update Post" or "Update Page" (versus initial caption of "Update")

[kevinB]

A few other anomalies I noticed:

1) Contributors can "edit" their own privately published posts, but saving throws it Pending Review status. I'm guessing this is not intended, and can address it as part of #14122 unless someone objects.

2) Contributors can save a post password to a Pending Post via Quick Edit, but not via the full edit form. The post remains in Pending Review status but retains the password if it is published. What is the intended behavior?

3) Setting the post date to future recaptions the publish button to "Schedule" if visibility is set public. But for private visibility, it retains the "Update" caption. Wouldn't it be better to show "Schedule" regardless of visibility - as a visual cue that the privately published post is about to be unpublished until the selected date?

[kevinB]

I've scrutinized the patch quite extensively and believe it to be cleanly coded, logically consistent and functionally correct. If ptah, nacin and others have just not had time to look at it, no problem. But I'd like to know if you're seeing issues with it.

What else should I do to bring it toward commit eligibility? I know it seems like a big diff, but the changes all fit together toward the goal of custom stati in the post submit UI and a backend that makes those selections a reality.

#14122 would be easier to address if I knew whether my $status_obj->moderation property and status caps approach will fly.

I can explain the reasons for each change file by file, or further describe motivations and use cases. Would either of those be helpful?

[kevinB]

plugin to demonstrate custom stati "Approved" and "Secret". Corresponding roles of "Reviewer" and "Super Editor". v 1.1 adds registration of custom public status "Alternate" for post type and custom private status "Confidential" for page type.

[kevinB]

Just updated the ​patch and ​demo plugin to:

• support type-specific status registration
• fully support custom public stati in the post edit UI, Edit Posts listing and everywhere else
• support scheduled publishing to any public or private status. Previously, selection of private visibility forced post to be published immediately despite selection (and storage) of future date

Type-specific stati (governed by $status_obj->object_type array) can be registered in two ways:

• register_post_status now supports object_type in $args array; registers the status to all object types by default
• register_status_for_object_type( $post_status, $object_type ) - Add an already registered post status to an object type

Enforcement is via

// $post_type may be an individual value or an array
$private_stati = get_post_stati( array( 'object_type' => $post_type, 'private' => true ) );

To make that work, I had to modify function wp_list_filter to support the array value intersection:

function wp_list_filter( $list, $args = array(), $operator = 'and' ) {
	if ( empty( $args ) )
		return $list;

	$count = count( $args );

	$filtered = array();

	foreach ( $list as $key => $obj ) {
		$matched = array_intersect_assoc( (array) $obj, $args );

		foreach( array_keys( $matched ) as $_key ) {
			if ( is_array( $args[$_key] ) ) {
				if ( ! array_intersect( $args[$_key], $matched[$_key] ) )
					unset( $matched[$_key] );	
			}	
		}

		$num_matched = count( $matched );
		
		if ( ( 'and' == $operator && $num_matched == $count ) || ( 'or' == $operator && $num_matched ) ) {
			$filtered[$key] = $obj;
		}
	}

	return $filtered;
}

get_post_stati() and get_taxonomies() cast object_type argument to array to ensure the special treatment.

Please let me know what needs further explanation.

[kevinB]

comprehensive support for custom stati (public, private and moderation). RevC tightens code, fixes patch js bugs and a few core bugs (see comments). RevD registers and enforces type-specific stati, fleshes out custom public stati, allows scheduling to any public or private status. RevE is a 1-liner to include all readable stati in Recent Posts widget. RevF (15 Oct) fixes patch bugs related to sticky posts; supports custom public stati for sticky posts, term count, comment feed, archives, find posts, nav menu metabox & display

[kevinB]

Updated ​patch fixes patch bugs related to sticky posts, defaults recent posts query to public stati only, and adds custom public stati support for:

• sticky posts
• term count
• comment feed
• archives
• find posts
• nav menu metaboxes and display

Also adds filters to support adjustment of those included stati:

• 'posts_sticky_stati'
• 'term_count_stati'
• 'comment_feed_stati'
• 'getarchives_stati'
• 'find_posts_stati'
• 'nav_menu_stati'

Also adds filters for default stati in the posts query (to support plugins dealing with content permissions):

• 'posts_public_stati'
• 'posts_private_stati'

[markmcwilliams]

Replying to ptahdunbar:

Registering a post status via register_post_status() doesn't show the new status anywhere in the admin. [...] Post statuses should be registered to one or more post types.

Got a BIG +1 from me, interesting stuff happening though!

[jane]

There are just a few days left before freeze, so asking committers to take a look and see if it can be finished off for 3.1 or not.

[nacin]

This is a huge undertaking, but I don't think we should rush this into 3.1. This looks like a great starting point. I'll support it as a task for 3.2 and I would be willing to work through it once we branch.

[ryan_b]

One thing I should note, there should be an argument to hide a post status and an argument to limit what post types it can be used with, especially now that we have custom post types, maybe I want a status just for my custom post type. Or maybe I want a staus that can manually be selected it must be added by my plugin for whatever reason.

Just my 2 cents.

[ucfknight10]

what is the status of this ticket? as in, any idea when it will be completed and implemented? i'm writing a plugin for a client that allows the author of the post to set an expiration date, so i've created a post status called "expire" using register_post_status, and i would like to see this ticket implemented into wordpress soon. so, any news?

*withdrawn*

[wlindley]

Replying to ryan_b:

...and an argument to limit what post types it can be used with, especially now that we have custom post types, maybe I want a status just for my custom post type...

Support. There needs to be an argument to register_post_status() whose value is an array of already-registered post_types to which the new post_status applies.

Alternately, register_post_type() could take an argument whose value is an array of already registered post_status values.

Furthermore, as of v3.1.3, the preamble to post.php contains eight calls to register_post_status, which are ignored by get_post_statuses() and get_page_statuses() -- which both are hard-coded, not to mention which line 109 says:

	register_post_status( 'pending', array(
		'label'       => _x( 'Pending', 'post' ),

while line 589 disagrees, returning the label:

		'pending'		=> __('Pending Review'),

Regardless, surely both get_post_statuses() and get_page_statuses() should simply return the data created by register_page_status() and register_post_type().

[nacin]

Replying to wlindley:

Regardless, surely both get_post_statuses() and get_page_statuses() should simply return the data created by register_page_status() and register_post_type().

I believe those are just used for XML-RPC. The function to fetch statuses would be get_post_stati().

[scribu]

Related: #17906

[simonwheatley]

Related: #18578 (didn't spot this when I submitted mine)

[kevinB]

The patch functionality (custom privacy and moderation statuses) is now implemented via ​plugin.

[lightningspirit]

How is the status os this patch? Will this be implemented in 3.4? Do you need any help testing and implementing it? I can help with anything implementing this API, but I don't know where to start it.
Can you please nacin or anyone else give me some directions?
Thanks

[westi]

This has a lot of discussion and patch work that we should consider what we want to do API wise to improve post_status support in core and what we don't want to support.

[sirzooro]

Please also add new function post_status_exists( $post_status ) - sometimes it may be handy to check if particular post status is registered. You can also add 2nd param $post_type, to check if post status exists for given post type (optional param, defaults to all post types).

[markoheijnen]

When this will be implemented this should also be implemented in xml-rpc. At this moment it is hardcoded.

[scribu]

This needs a dedicated sub-team, if it's ever going to get off the ground.

[danielbachhuber]

I'm happy to help on a subteam... I've done a lot of work with custom statuses and have a good understanding of where the weaknesses are.

[scribu]

I'm also willing to help, but it's too late for this in 3.4 (we're theoretically past freeze: ​http://wpdevel.wordpress.com/version-3-4-project-schedule/).

[lightningspirit]

Hi to all,
I really would like to help this topic and be also part of this subteam.
I think we need this feature in WordPress. I made some developments about this stuff in my instalations and I have some custom post types using this "meta" feature. I would like to contribute with them.
How can we join efforts to proceed with this?

[philipjohn]

I brushed up the ​Codex article on this today and subsequently found this ticket. Adding myself to updates.

[scribu]

Related: #20188

[bergius]

Why is this ticket keep sending me notices when I've removed myself from the cc list?

[scribu]

Because trac starts sending you notices the minute you do anything on a ticket: add a tag, add yourself to cc.

Please open a new ticket with the WordPress.org component to discuss this further.

[benbalter]

Updated patch to run with trunk, few bug fixes here and there

[benbalter]

Uploaded attachment:12706.diff​ which ports the existing patch forward to work with trunk (r20434).

Also fixed a few bugs, and in the process, created a new get_object_stati() function (mirrored off of get_object_taxonomies()) to deal with wp_list_filter not liking nested arrays (specifically the object_type arg).

Still testing, and I'm sure there's stuff I missed, but worksforme.

[kevinB]

Although custom moderation and private stati are clearly useful and mesh well with the existing post_status implementation, custom public stati seem questionable. Can anyone think of a scenario in which they would be beneficial? All that comes to mind is:

1. a single-term pseudo-taxonomy (probably unnecessary)
2. allowing for distinctions in editing access without altering read access (potentially useful but arguably cludgy)

I'm not arguing for or against; just think it should be discussed before any code commits.

Another suggested topic for conversation: capability definitions and requirements related to custom stati. Any solution needs to regulate read, edit, delete and set (i.e. publish) of each custom post status, for each post type. The current patch does address these (just inviting further ideas).

[benbalter]

Replying to kevinB:

Although custom moderation and private stati are clearly useful and mesh well with the existing post_status implementation, custom public stati seem questionable. Can anyone think of a scenario in which they would be beneficial?

Anything that's not a blog post; that you don't "publish." If the final step of my workflow is "submitted" (think malange with applications) or "final" (think alfresco with press releases). If I'm a news organization and want to have a "breaking" post status at an intermediate step in my editorial process to display a teaser on the front-end. If I'm a car dealership (think autorader) and use my cars custom post type as either "available" (listed) or "sold" (not listed). If I have a coupon site (think retailmenot) in which everything is either valid or expired. Anytime a post isn't a blog post. (not to mention it's kinda silly to abstract 2/3s and hard code 1/3 which makes building queries, etc. a bit less intuitive).

[kevinB]

Replying to benbalter:

Anything that's not a blog post; that you don't "publish."

I don't follow the correlation between being a blog post and having 'publish' status. Pages and other custom types have post_status = 'publish' too.

My working concept of the three post_status types:

1. $status_obj->public : published to everyone
2. $status_obj->private : published to those with sufficient capabilities
3. $status_obj->moderation : not published at all, and editable based on capabilities

Maybe you would rather rename (3) to "workflow" or something else, but I don't see "something you don't publish" as a public status.

If the final step of my workflow is "submitted" (think malange with applications) or "final" (think alfresco with press releases).

"Submitted" is a moderation status in my book (not yet public).

"Final" would mean public but no longer editable by anyone, right? If so, that says my scenario (2) is real world and there are usages where a sequential post_status workflow that retains visibility but changes editability is not a cludge. Glad to hear it.

If I'm a news organization and want to have a "breaking" post status at an intermediate step in my editorial process to display a teaser on the front-end.

That's a compelling feature, but how would you retain that "breaking" flag and track progress through various steps of moderation, all with a single post_status field? Or do you have some other schema in mind to implement these stati?

If I'm a car dealership (think autorader) and use my cars custom post type as either "available" (listed) or "sold" (not listed).

If you want it for display customization, that sounds like a good job for a custom taxonomy. If for suppression (non-publishing), it sounds like a workflow status, not a public status.

If I have a coupon site (think retailmenot) in which everything is either valid or expired.

Same as above.

(not to mention it's kinda silly to abstract 2/3s and hard code 1/3 which makes building queries, etc. a bit less intuitive).

Yeah, I already wrote the code to implement custom public stati. Just wanted some confirmation that it's worthwhile and optimal.

[sirzooro]

@kevinB: in fact post statuses are a special kind of taxonomy, dedicated to manage "post" workflow. In addition they have extra support for visibility in core - depending on status post may or may not be displayed on front side. In general that extra support in core should let you decide what is better: custom post status(es) or custom taxonomy.

Few extra examples:

• product page: draft, published, not available (temporarily), production stopped (page not visible);
• ticket workflow: new, assigned, resolved, verified, closed, rejected;
• movie page (for cinema): draft, screening/preview (there may be few of these), released, end of the screening;

[alexkingorg]

I see status as internal workflow data. If you want to store data for decorating posts, that's where you want to use post meta. If you want to store data to use to query for specific posts, that would be a good place to use a custom taxonomy.

[kevinB]

Currently, post_status is used to track workflow until publication. Then, upon publication it is primarily a visibility control (with corresponding editability control).

The current patch would expand that model as follows:

1. additional moderation/workflow stages prior to publication (with corresponding set/edit/delete caps)
2. additional visibility (privacy) statuses
3. additional public statuses, which could be used to indicate further post-publication workflow (with possible distinctions in editing access)

The problem I see with (3) is that it could quickly overtax the one-status-per-post schema. What if you have already used a custom privacy status to customize visibility, but now want to make the post "final"? It seems that further post-publication editing access would be better handled via a separate status field that is dedicated to editability. If that is better left to a plugin, no problem ;)

Replying to sirzooro:

@kevinB: in fact post statuses are a special kind of taxonomy, dedicated to manage "post" workflow. In addition they have extra support for visibility in core...

[benbalter]

Updated patch with bugfixes, refinements, and lastest trunk

[benbalter]

Hoping to keep the ticket alive and kicking as planning gets under way for 3.5... updated the patch (attachment:12706-1.diff​) with bug fixes and refinements and moved to latest trunk.

Although a bit rough around the edges, it appears to be somewhat stable for day-to-day use (I run it on a development box), and hooking into the API described above is fairly straightforward.

Outstanding: Potential tweaks to the publish metabox and quick edit

[Viper007Bond]

Was disappointed to find that you can't register a custom post type to just a specific post_type like you can with a custom taxonomy and finally found this ticket. Would be great to get this into core.

[williamsba1]

Is there any movement on this for 3.5? I'd love to see this get in this version!

[markoheijnen]

For this getting in 3.5 it needs a lot of unit tests since the code will be changed a lot.

Looking trough the code I was wondering how the default statuses will get registered to the default post types. I'm probably missing something. Also doesn't it make more sense to create a WP_Post_Status class instead of using a global for that?

[JustinSainton]

This would be super slick. With as much traction as this has, and considering this is between hard and soft freeze - I'm curious as to whether or not this is too ambitious to consider this cycle, or if it's something we can mark as 3.6-early?

Personally, I'd be happy to contribute and invest some time for this cycle.

[scribu]

If you want to make this get into Core faster, write some unit tests:

​http://make.wordpress.org/core/handbook/automated-testing/

Unlike normal patches, unit test patches tend to get commited faster and don't get stale as fast.

[helenyhou]

Also, as is noted, it needs a refresh. Been keeping an eye on this in relation to some parts of #21391.

[JustinSainton]

Good points. @ryanduff and I will take some time in the next week or so to refresh and start some unit tests.

[nacin]

While important, I don't think it's only a matter of only a refresh and unit tests.

I've chatted with benbalter about this a few times. He studied the original patch for easily 10+ hours while updating it to trunk, so he's quite familiar. But he also didn't make any changes to it, instead simply refreshing a two-year-old patch based on a two-year-old API proposal.

I think, and he agrees, that the API as proposed is lacking, confusing, and needs some work.

My initial thoughts on reviewing it are:

• The JS has a lot of room for improvement. Part of that is due to the age of the JS for the existing publish meta box.
• The meta box code has a lot of room for improvement. Rather than being a somewhat elegant status API, it looks like a complete hack. Again, a lot of that is due to the existing code.

• The "moderation" property is confusing and ill-defined.

• Seems like we need a new query var. We currently have post_status = 'any' (along with post_type=any) as a "meta" status that maps to everything. This whole thing seems like a ripe situation to take the post_status and perm query variables and make them better.
• That capabilities.php is untouched in the latest patch is incredibly odd, to say the least. map_meta_cap() supports custom post types and needs to support custom statuses for both built-in and custom post types.
• When it comes to capabilities.php and query.php, the left hand doesn't talk to the right hand. The previous two bullet points outline the two different systems, which really shouldn't be two completely separate systems.

• I randomly noticed that wp_count_posts() goes from 'draft, publish, future, pending, private' to only public statuses. There are many instances of raw SQL queries being changed — we need to thoroughly review these and ideally avoid direct SQL as much as possible.

• The concept of a "scheduled status" (a post having a status outside of the fact that it is in the "future") is nice. Perhaps this should be spun off and implemented separately from custom post statuses. There's just too much going on here, and that seems like a good thing to start with. There are likely other things that could be done or spun off. For example, why must a "published" post have a date in the past? (Think an event in the future.) I'm not even sure if the API as designed handles that.

Overall, there's just so much to consider here, there's really no way it is happening for 3.5.

[kevinB]

Replying to nacin:

• That capabilities.php is untouched in the latest patch is incredibly odd, to say the least. map_meta_cap() supports custom post types and needs to support custom statuses for both built-in and custom post types.

The lack of change to function map_meta_cap() is explained by the patch's plugin roots. It can be filtered to apply additional capability requirements based on $post->post_status (as demonstrated in the old status-helper.zip). Maybe inelegant, but not that odd.

• The "moderation" property is confusing and ill-defined.

Call it what you want, the idea is to allow for multiple statuses between draft and published, rather than hard-coding 'pending'. Each of those "moderation" statuses should have its own capability analogous to "publish_posts", as well as edit and delete caps. API should also allow control of which status (i.e. "Reviewed", "Approved" or "Dissed") is set by the "Publish" button when the user cannot publish.

[BjornW]

Maybe I've missed this so please excuse me if this point has already been made (feel free to point me towards it).

I'm wondering if the current discussion on custom stati includes the possibility of having a published post/page workflow which has a new version currently in progress without taking the current version offline? Basically the ability to work on new drafts without having to take the current version offline akin to how autosave currently works.

A possible example use case could be:

Ann is an author who blogs about legislation. She wrote a post on law X some time ago. This law X is in the process of being be changed. She would like to update her old post on this law X, but keep the current version still online until the changes in law X have been agreed upon. In the meantime however she would like to update her old post, save the changes, but not make these changes public nor take the old post offline. She continues to work on her changes saving them, occasionally she invites a peer to have a look at her work and all this time the old post stays the same & online. After the changes in law X have been agreed upon she makes her changes public and this updates her old post online.

As far as I know WordPress does not support this use-case currently and it would be very nice if the new custom stati API would support these type of usecases where the publicize workflow of WordPress could be enhanced.

Btw the use-case described above is derived from both corporate & government clients who have a need for a more moderated publicize workflow due to the nature of their content, which for instance may be used in legislation.

If there is anything we can do to speed up the inclusion of this in the stati API, feel free to contact me.

[sbressler]

Replying to BjornW:

I'm wondering if the current discussion on custom stati includes the possibility of having a published post/page workflow which has a new version currently in progress without taking the current version offline? Basically the ability to work on new drafts without having to take the current version offline akin to how autosave currently works.

Not that this necessarily solves your entire use case, but ​Revisionary already handles a lot of what you're asking for.

[BjornW]

Replying to sbressler:

Not that this necessarily solves your entire use case, but ​Revisionary already handles a lot of what you're asking for.

Thanks we had a look at the code of Revisionary and frankly I found at very large (loads of code which seems to be part of somekind of homebrew framework) & at first glance messy. Although it does work as advertised :) I might use it as a reference for a smaller plugin.

[nacin]

Ben Balter (who has been active on this ticket) has been working with a few others on a Post Forking plugin. I'd start there! ​https://github.com/benbalter/post-forking

[BjornW]

Replying to nacin:

Ben Balter (who has been active on this ticket) has been working with a few others on a Post Forking plugin. I'd start there! ​https://github.com/benbalter/post-forking

Nacin, the link is dead & I don't see any repo resembling 'post-forking'? Are you sure it's called like that?

[BjornW]

The link is now alive: ​https://github.com/benbalter/post-forking
and more information can be read here: ​http://postforking.wordpress.com

[nacin]

#23174 was marked as a duplicate.

[kovshenin]

In 12706.2.diff​ took a stab at the "statuses in post types" approach, briefly discussed in IRC. You can register post statuses to post types in register_post_type by using the statuses array:

'statuses' => array(
	'pitch' => array(
		'label' => _x( 'Pitch', 'book' ),
		'label_count' => _nx_noop( 'Pitch <span class="count">(%s)</span>', 'Pitch <span class="count">(%s)</span>', 'book' ),
		'public' => false,
		'protected' => true,
	),
),

Statuses registered with register_post_status will be applied to all post types. If this approach looks reasonable, I'll continue working on some of the other parts touched by the earlier patches.

[ramiy]

Related #23207

[sirzooro]

Replying to kovshenin:

Statuses registered with register_post_status will be applied to all post types. If this approach looks reasonable, I'll continue working on some of the other parts touched by the earlier patches.

Please add option to disable this - some plugins may want to register post status first using register_post_status, and then explicitly attach it to selected post types.

[kovshenin]

Replying to sirzooro: That's only for backwards compatibility reasons. Also see #23169

[kovshenin]

In 12706.3.diff​: still haven't touched any user facing parts, same as .2.diff with the following additions:

• New WP_Post_Status class which is used by register_post_status, register_post_type, and possibly register_post_status_for_object_type (see #23169)
• New status attribute show_in_admin_status_dropdown which tell whether the post status should be displayed in the Publish metabox dropdown. It defaults to false and basically prevents a bunch of custom statuses to suddenly show up for all post types after an upgrade to 3.6.
• Another status attribute priority which defines whether a post goes through "Draft - Pending - Publish" or "Pending - Publish - Draft" so the one with the lowest priority (usually Draft) will also define what's the default status for new posts. A new function _sort_post_statuses which sorts by priority.
• A capabilities array, for now only defines the transition_post capability map which defaults to edit_post, and set to publish_post for the Published post status. This allows us to check whether users can change a post to a certain status upon save, etc.

Thoughts? Feedback? How does this look? Question: do you think register_post_status should be deprecated in favor of status registration with register_post_type and register_post_status_for_object_type?

[danielbachhuber]

12706.db.1.diff takes Kovshenin's patch and does the following:

• Drops the 'priority' and 'capability' arguments. Priority is largely UI-related which we can work on later, and caps are outside the scope of this ticket.
• Adds a 'moderation' argument for registering post stati to bucket 'draft' and 'pending' stati separately from 'future'
• Completes the post status => post type implementation such that get_post_stati() by a post type actually works. I changed the filter argument to 'post_type' because post stati will only be registered to posts. The somewhat lame thing is that new WP_Post_Status objects can live in two or more places: $wp_post_statuses global and with each post type. Not sure how we want to reconcile this.
• Starts the implementation of exposing newly registered stati in the admin. This particular patch just works for the Manage Posts screen and things like _post_states() need to be updated.
• Starts the abstraction of hard-coded post stati references in other APIs.

I think I'm going to wait on touching the publish meta box until we have some direction on the other part of the project, and instead will continue playing whack-a-mole with the hard-coded references.

[ramiy]

Replying to danielbachhuber:

Consider applying ticket #23207 in your patch - Using $labels argument like it's done in register_taxonomy() and register_post_type().

See ticket #23207 and ​GenerateWP.com (compare the taxonomy-labels and the post-type-labels with post-status-labels).

This way, we would create a standard way to add translation strings to register_{taxonomy|post_type|post_status}() functions.

Just a thought.

[danielbachhuber]

12706.db.2.diff is my first patch plus the following:

• Abstraction of the Publish meta box such that custom moderation statuses can appear in the dropdown, and contributors can submit to the next moderation status.
• _post_states(), which is used in the Manage Posts list tables, will now add all 'protected' statuses, which includes 'draft', 'pending', and 'private'
• Implementation of a 'labels' argument when registering custom post statuses
• get_sample_permalink(), and editing a post slug, no longer breaks when a post is saved to a custom moderation status

If you apply the patch, you'll notice there's a JS error when you change a post to a custom moderation status and hit "OK". There's a @todo marker in the patch for this. Essentially, I'm loading the post status data to the clientside using the script loader. The script loader fires too early though (on init:0) for any custom statuses to be registered.

At least these two big areas still need to be touched:

• QuickPress / PressThis
• XML-RPC

Here are some pieces I ran into confusion about:

wp-admin/includes/post.php:post_preview()

• 'draft' posts fire edit_post(), where as others do wp_create_post_autosave()
• Two ways of redirecting to a preview link depending on draft vs. pending

wp-admin/includes/post.php:_wp_translate_postdata()

• A bunch of different types of input buttons are interpreted

wp-admin/includes/post.php:wp_edit_posts_query()

• Couple of hardcoded references to 'draft' and 'pending'

Lastly, I've started logging the individual changes I'm making (and justification) on my Github fork: ​https://github.com/danielbachhuber/WordPress/compare/master...12706-custom-status

Would love to have others play with this code and offer feedback during Tuesday's chat.

[kovshenin]

Replying to danielbachhuber: Here's my feedback after applying your patch to a clean trunk:

• Once a post is published, there doesn't seem a way to go back to draft or other statuses from the edit post screen
• "Private" labels are gone for private posts in the posts list
• When saved for review, the submit button says "Submit" and does the same as Save (contributor)
• I noticed the save_next argument in the post statuses labels, not sure I understand that. I think each status should have the transition_to label instead, because you don't always transition from draft to pending. So "Submit for Review" will be the transition_to label for pending. "Save as Draft" for draft posts, etc.
• Have we decided whether we're keeping the status class or not?

I'm also confused about edit_post, autosaves, previews and revisions.

[danielbachhuber]

12706.db.3.diff hits the first two issues. Here's the relevant changesets:

• ​https://github.com/danielbachhuber/WordPress/commit/5d6e7933e8f3cca5c5cc901db46a07d8fdf7b81c
• ​https://github.com/danielbachhuber/WordPress/commit/ed89961bde52403a34badfc6d0d2a97c53517a65

For the third, I'm not sure what the behavior should be or whether we should just continue supporting the contributor model as it exists now.

For the forth, I dig that idea. We need a cleaner way of getting the "next" or "previous" status though.

Lastly, I'm digging the status class now. It seems like a better way of enforcing a common post status object. I suppose we can hear the objections against tomorrow.

[markoheijnen]

I guess this is future release now? Any change we can move this development to a github repository?

[alex-ye]

I hope to see more active on this ticket , It make our life easier !!

[sworddance]

(Comment from #7745 that seems to be relevant - this comment is more expanded)
It seems the real problem is that there are 2 orthogonal issues at work that are not being treated orthogonally: Visibility and Status.

Currently ( 3.7-alpha24822 ) there are very bizarre interactions as a result.

Interaction path 1:

1. Create a post
2. Change its Visibility to Private
3. Status now changes to 'Privately Published'
4. Status does not have an edit link any more

Interaction path 2:

1. Create a post
2. Click on Status edit button (so the status selection box is displayed)
3. Click on Visibility Edit button
4. Change Visibility to Private
5. Click on Visibility 'OK' button
6. Status option box changes to allow 'Pending Review', 'Draft', 'Privately Published'
7. Select 'Draft' and click on status 'OK' button.
8. Status becomes 'Privately Published' ( not Draft like user requested ) and the edit button disappears.

Interaction Path 3:

1. Create a post
2. Click on Status edit button (so the status selection box is displayed)
3. Click on Visibility Edit button
4. Set the scheduled time to be in the future
5. Change Status to be private
6. Post published and the scheduled time is still set to be the future.

Comments:

1. Visibility and Status are not logically the same :
   1. Visibility is the MAXIMUM POSSIBLE visibility.
   2. Status is a WORKFLOW STATE that may impose a maximum calculated_visibility
2. If Visibility controls Status then Status should be visually subordinate to Visibility. Currently it looks like Status should control visibility. (which from a work flow perspective I would think that it would be the case.)
3. Visibility and Status interact in a non-intuitive manner.

Suggestions:

1. Status should be used to determine the CURRENT maximum visibility of a post.
2. Visibility determines the absolute maximum visibility of the post.

so conceptual the question is :

current_user_can('read_post', $post_id) ;

with the answer being determined by:

$actual_visibility = max ( status_max(), visibility_max(),
<some calculation depending on current_user's relationship to the post>, <posting_schedule>, <other filter functions > )

[sillybean]

#12510 was marked as a duplicate.

[rickalee]

Any hope of this getting picked back up for 3.9? Tempted to apply Daniels patch to get this working on internal project.

[helen]

I would love to see this taken on again, although I don't think it should be promised for a release until the UX and ensuing UI and API are thought through. I think it's important to note the order there - I understand that the instinct is to go for API first (I'm a developer, too, I more than get it), but I think what we're really battling here is growing pains, not just a broken API. We need to focus on what the UX should be, first from a default standpoint, then from a "what COULD people want to do" standpoint, and then determine what UI and API changes need to happen from there.

For example, let's take a pretty common custom workflow of "I save a post, somebody else copyedits it, and somebody else actually publishes it". What does each user type's workflow look like when they're in the admin (possibly not even just the edit screen)? How can the admin help guide them to the best or right action or set of actions to take? From there we think about how an ideal UI would be structured and what an API would need to support for that scenario. Then, through considering various and varying scenarios, again starting with existing default ones, we can come to what kind of extensibility the UI needs to account for and, of course, what the API needs to look like to make it all actually work and to allow developers to mold and customize as needed.

I'd love to explore this some more and plan on doing so in the near future, and invite anybody else who has some thoughts to do the same. comment:162 is a nice breakdown of the current "flows".

[danielbachhuber]

Once a project hits a point where it requires a more complex workflow than what WordPress offers out of the box, all bets are off. I don't think we can or should solve that problem in core. However, I think core should have APIs that fully support more complex publishing workflows.

If I were to pick up development on this again, I would likely follow this approach:

1. Identify five or more use cases for more complex publishing workflows with sufficient detail that it's possibly to understand the commonalities between them.
2. Discuss how the commonalities could be better supported by core.
3. From the commonalities, define the problem to be solved. Get buy-in from a core committer or two.
4. Build a library to support the commonalities. Should it prove useful, include it in core.

I don't think this ticket has ever really gotten anywhere because everyone on it has been trying to solve different problems, and there hasn't been a core committer yet who just takes an idea and runs with it.

With that being said, I think you could reach out to participants on this ticket with a survey and get sufficient detail for your five or more use cases pretty quick.

[MikeSchinkel]

Replying to helen:

then from a "what COULD people want to do" standpoint, and then determine what UI and API changes need to happen from there.

That seems like a rather large scope for core development. Maybe not for a "Feature-as-a-plugin", but definitely for core-focused features.

Replying to danielbachhuber:

If I were to pick up development on this again, I would likely follow this approach:

1. Identify five or more use cases for more complex publishing workflows with sufficient detail that it's possibly to understand the commonalities between them.
2. Discuss how the commonalities could be better supported by core.
3. From the commonalities, define the problem to be solved. Get buy-in from a core committer or two.
4. Build a library to support the commonalities. Should it prove useful, include it in core.

That also seems like quite a large scope, and part of the reason this ticket is 4 years old and still not addressed.

I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.

Lack of custom statuses in the UI is a big missing piece in core (considering core has register_status()) and something for which I've had to revert numerous times to a very hackish use of ob_start()/ob_end_clean() to correct.

Once custom statues have appeared in the core UI then we can more easily identify specific workflow use-cases that deserve to be in core, and then each of those independent issues can get their own ticket in core.

JMTCW.

[bradt]

Completely agree with @MikeSchinkel. The small scope he describes is all that I was looking for when I joined this ticket. Perhaps it would be best to create a new ticket that describes this much reduced scope? Something like "Add custom post status to status select box on edit post screen"?

[helen]

Replying to MikeSchinkel:

I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.

It isn't simple. The existing metabox makes almost no sense when you step back and look at it. Visibility and status are separate in the UI, but not in the data, and they mess with button labeling in different and sometimes unpredictable ways - how can we add to this in any sane way? Shoving more in there just makes it even harder to change later.

I don't think core should be providing non-default workflows at all, and I'm sorry about not being particularly clear about that - I just think that once we're talking about supporting custom statuses, we should take at least a few minutes to be considerate of what developers are doing with that. Even if the end result is simple (and, dare I hope, a simplified UI), a little consideration goes a long way so that people don't end up still having to do lame hacks, just in different places. I'm not calling for creating formal personas and scenarios or anything like that here - just a look at some of the bigger parts of the picture.

I have no preconceived notions on how involved or big changes to UI and API might be. I just think there's value in a UX-first approach, especially when it comes to trying to avoid hampering extensibility or the future. Again - that UX part of the discovery process could take a total of 10 minutes. I don't know. I don't think we're actually conceptually at odds here. And, after all, it's also just my two cents.

[aaroncampbell]

Replying to helen:

Replying to MikeSchinkel:

I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.

It isn't simple. The existing metabox makes almost no sense when you step back and look at it. Visibility and status are separate in the UI, but not in the data, and they mess with button labeling in different and sometimes unpredictable ways - how can we add to this in any sane way? Shoving more in there just makes it even harder to change later.

There's more that's making this "not simple" than just the UI too. There's also the issue that we hardcode "publish" as the only status for published posts. This means that we need filters in several other places unless we relegate custom statuses to being all non-published. For example, an "archived" status that is still live (but is maybe used to prevent it from being edited), wouldn't work.

[sillybean]

A lot of status lists and transitions are hard-coded. What I'd like to do is make all those lists filterable and the actions variable (e.g. $status-to-$status). Then a developer wishing to implement a custom workflow could add the custom status to the filtered list and use the actions to implement whatever additional functions (like email notifications) are needed.

[nacin]

I think there are two very different ways to approach this. I don't think they are mutually exclusive, but they are different worlds in complexity and approach.

1. A custom post status is nothing more than an alias/rename/copy of an existing status.

A status like "Sent to Editor" is really just "pending" under the hood. Or a status like "Active" is really just "publish". There is no "expired" post status in WordPress, so "Inactive" doesn't translate directly to any existing status, but it's more or less "trash".

So, we should build something that simply allows you to declare a new status with a few basic flags that make it mimic the functionality of an existing status. If you're building out a proper workflow, is "For Copy Editor Review" really anything different than "Pending" other than the name?

And at that point, I begin to wonder if an actual "aliases" API is most helpful. And if a post is pending review ("Pending"), who is it pending review for? Is it really necessary to have a separate "status" for each desk a post needs to reach (I'm thinking newsroom, but you can probably extrapolate this for other workflows), or is it just a piece of metadata tied to the post that allows us to say "oh yes, it is assigned to Helen for review". It's still "Pending", so does it really matter what its status is?

So, very simply, I've yet to see some solid use cases of custom post statuses that aren't just renames/aliases of existing functionality.

2. A custom post status API requires us to tackle the world of transitions. It's not just that a post can be one of X statuses, it's that based on the current status, and the current user, it can be promoted/demoted to one of X statuses.

Does that mean current_user_can( 'transition_post', $post_id, $new_status )? Probably. And you'll note that if $new_status = 'publish', then this is basically just current_user_can( 'publish_post', $post_id ) — see, we already have a publish_posts capability to extrapolate from. Now someone could implement fine-grained control, without us getting into the workflow business. Maybe.

While a concept like transition_post can handle authorization, it doesn't necessarily handle UI options. Given status A, what statuses can you go to? How does that change affect its spot in a pending moderation queue? Or is it considered "draft"? Or is it considered published? Do we have to implement something like Trac's ticket status workflow? (It's kind of insane, but ​here's a primer.)

What does a custom post status actually mean? I don't know -- I've been thinking about this for four years and still don't have an answer.

[rickalee]

I strongly agree with Nacin's alias approach. Typical use cases are other names for Pending that may/may not trigger email notifications.

The only use case outside of Pending that I have had is make a Trash-like alias of 'Inactive' on a CPT that doesn't clear after 30 days that removes it from 'show_in_admin_all_list'

[obrienp]

I second Nacin's approach. My use case is using CPT's which have a custom status "traffic light" that can determine the status of a client at quick glance.

Using Custom Post Status would help sort these CPTs into groups (e.g. "Booked", "Not Booked", "Waiting on Client", etc.)

For me the alias is a great idea, since these custom post status' are really just the same as Published/Private.

[MikeSchinkel]

Replying to nacin:

So, we should build something that simply allows you to declare a new status with a few basic flags that make it mimic the functionality of an existing status. If you're building out a proper workflow, is "For Copy Editor Review" really anything different than "Pending" other than the name?

So I assume that an existing status could be aliased multiple times?

Then, would the aliased status be stored in the post_status field (i.e. '4ce_review') or would 'pending' still be stored and if so how would the "For Copy Editor Review" be associated? Also, how would developers be able to implement efficient SQL queries to retrieve just the posts for a given alias status when there are multiple aliases for the same existing status, i.e. as "For Tech Review" might also be a legitimate 'pending' status?

As for flags, I scanned through core's source code and it seems that some of the use of status is specific to status, i.e. omit 'trash' posts in a list of posts unless displaying the list of items in trash. But other uses of status seem to point to what a given status implies, or more importantly what all other statuses imply. This leads me to think that a "Post Status Supports" concept would make sense, and here are some of the one's I quickly identified:

post_status_supports( 'revisions' )
post_status_supports( 'sample_permalink' )
post_status_supports( 'last_edited' )
post_status_supports( 'editing' )
post_status_supports( 'editing_attachment' )
post_status_supports( 'commenting' )

With a post_status_supports() function it would seem we could evolve a lot of the code that operates on happenstance and instead actually focus on the (currently implicit) logic needed. With this approach and a related filter hook, plugin and themes could add their own statuses (or status aliases, however it plays out) and if they want their status to support editing but not revisions, then they would have control to do so and core would support their new statuses.

And at that point, I begin to wonder if an actual "aliases" API is most helpful. And if a post is pending review ("Pending"), who is it pending review for? Is it really necessary to have a separate "status" for each desk a post needs to reach (I'm thinking newsroom, but you can probably extrapolate this for other workflows), or is it just a piece of metadata tied to the post that allows us to say "oh yes, it is assigned to Helen for review". It's still "Pending", so does it really matter what its status is?

Actually with an addition of post_status_supports() I think aliases might be of less interest and frankly, aliases are less WordPress-ish. It would be similar to how post types can be extended with post_type_supports() and how we don't really depend on custom post types to be aliases of 'post' or 'page'. So instead of trying to shoehorn new potential use-cases into our existing known use-cases we can instead focus not on the status itself but the individual behaviors that each existing status implies and this support emergent use-cases we'd not previously realized.

So, very simply, I've yet to see some solid use cases of custom post statuses that aren't just renames/aliases of existing functionality.

I'm not sure lack of evidence is sufficient to prove lack of existence. Even so, by writing code to test "if a post status supports revisions" rather than "if it's neither 'auto-draft' and 'draft'" should allow for us to write more robust plugins and themes that are more resilient to change and the bonus is they would support valid custom post status use-cases if and when those use-cases emerge.

All that said, it's already possible to add new custom post status and because of that more than a few people have been using ob_start()/ob_end_clean() to enable them in the admin, or they've written custom metaboxes to support it. Thus adding the ability to also automatically display these custom post statuses will do no "harm" as there are custom post statuses in the wild within many WordPress databases, and they have survived without core's workflow supporting them. Why not at least close the loop on this and let us add in custom post statuses into the post add/edit UI while we wait on a better solution? And if not automatically, why not at least give us a filter hook so we can accomplish it without writing fragile hacked code?

[rezen]

I really think Nacin's second direction, workflows is the way to go. There are many use cases where the ability to have a stricter workflow would be beneficial. I also think workflows fit into the app engine direction WordPress is going for.

[knutsp]

I would go for the first direction nacin suggested, allow aliases, at first iteration. In a second iteration, later, implement alternative workflows, transitions and/or "supports" to statuses. May the first and simplest solution get in the way for future evolution?

The best solution sometimes becomes the enemy of a good solution.

[MikeSchinkel]

Replying to knutsp:

May the first and simplest solution get in the way for future evolution?

The simplest solution is to just include registered statuses in the drop down that allows a user to select a status before updating a post. Aliases would be much more work than that.

[knutsp]

Replying to MikeSchinkel:

Replying to knutsp:

May the first and simplest solution get in the way for future evolution?

The simplest solution is to just include registered statuses in the drop down that allows a user to select a status before updating a post. Aliases would be much more work than that.

May be - probably. But to show up in the drop down on the edit post screen, core needs to handle the status as if it was one of the existing. That is the reason this bug is still present. Some statuses trigger UI behaviour (because it means something, has semantics, to core), like changing the button text. May all registered stati be handled as an alias of draft, just to begin with?

Talking about the best solution is fine, when used to evaluate if a first, simple solution might also be a good, temporary solution. When the most visible bug here is gone, then the rest may be future enhancements. Then make a new ticket for that.

People, in thousands, are willing to settle on Mars, without any technology to return to Earth. We are, it seems, not willing to simply fix an old bug as long there isn't a path to CMS heaven included.

I want to go to Mars, one way, when that is the current option. Now, not waiting for a tested Mars-to-Earth commuter system to be in place.

[MikeSchinkel]

May all registered stati be handled as an alias of draft, just to begin with?

That's how I'd tackle it. Heck, using ob_start() and ob_get_clean() that's how I already handle it. But what a hack PHP caching is.

a first, simple solution might also be a good, temporary solution

Agreed.

I want to go to Mars, one way, when that is the current option.

Ignoring that you were using as a metaphor, you go right ahead. I'll stay here and you can send me ePostcards… ;-)

[toscho]

Whatever you do, please stop using stati as a plural. :)

The ​plural for the noun in English is statuses, in Latin statūs.

[nacin]

Replying to toscho:

Whatever you do, please stop using stati as a plural. :)

The ​plural for the noun in English is statuses, in Latin statūs.

We used get_post_stati() because get_post_statuses() was already taken for an XML-RPC function. Ideally we end up with get_post_type_statuses() — which is implying, yes, that we have per-post-type custom statuses. Which I glossed over above, but also needs to be figured out.

[kevinB]

Replying to nacin:

We used get_post_stati() because get_post_statuses() was already taken for an XML-RPC function.

Webster don't agree, but I've come to appreciate the brevity of "stati" (though only in code). I think WordPress has the standing and audacity to be an intelligent force in the ongoing evolution of language.

[F J Kaiser]

Replying to toscho:

Whatever you do, please stop using stati as a plural. :)

The ​plural for the noun in English is statuses, in Latin statūs.

I double that. Could we simply stay with either Latin or English instead of any ... custom variant? Whatever language that is: It has to go away. Now. Or better yesterday. It's already tough enough that we ain't really got a naming convention and that I have to rely on my IDEs autocomplete feature to maybe have a hit - not that it always will meet my requirements - but then as well having non-English vocabulary? Please be nice with us non native speakers and at least leave us the dictionary as last resort.

[sirzooro]

What is the status of this? It is too late for 4.0 now, but what about next release?

[WebTechGlobal]

I'm using 5 custom status for WTG Tasks Manager for a custom post type.

Posts using a custom status do not show on the All posts view - the query must still have the original core statuses coded.

[uxtremist]

Here's my case for additional post statuses:

For blogs.ft.com we have a custom post type called webchat, which is used for live sessions. These sessions are events, with a duration of an hour or so, where content is added in a real-time, instant-messaging, streaming fashion.

We still use the usual WordPress statuses (well, just Draft and Published, really).

I'd like to have a kind of sub-status feature in WP core, so that:

1. When a webchat post is first published, its status is "Coming soon". This lets users know when to tune in for the event, which is scheduled to start in a day or so.
2. When the event starts, the status is "In progress". We use the transition to trigger other things (that aren't important to this case, except that we do want to be able to hook the transition.)
3. When the event concludes, the status becomes "Closed". It's still published, but it's clear the event is now over.

Notes:

• Webchats appear alongside standard posts in the homepage loop, in other words they're treated as just another post.
• It would be beneficial to not only be able to add these semantic status types, but also alias them depending on different kinds of webchat session. For example, question-and-answer discussions (with multiple participants), as opposed to as-it-happens liveblogging (with a single author). Conceptually these are sufficiently different to warrant bespoke terminology for (what are essentially the same) statuses.

[chriscct7]

#21699 was marked as a duplicate.

[daniluk4000]

@wonderboymusic @danielbachhuber What are the approximate time of complete this API?

[chriscct7]

Please do not change the version

[Umbercode]

I am not sure this should be based on workflow or use-cases. Wouldn't it be beter to base this on the actual functionality of the status?
A post-type can have 3 possible states: published, unpublished and trashed. No matter how a status is called/named, the end result is one of these 3 functional states. So basically all we need is the ability to add aliases and an ability to include them in the status dropdown and/or post-type index and/or post filter.
So using the existing function register_post_status the $args argument should be extended with the following:

• post_type (any post-type slug(s) for post-types this status can be used on, should default to posts and pages?)
• post_state (can be published, unpublished or trashed, defaults to published?)
• show_in_publish_dropdown true/false (false as default I guess?)

With this you can make any number of statuses and use them any way you want. If you want to add something extra, an additional argument called 'color' could be introduced that adds a colour border to the post-type much like the blue border with plugins.

[helgatheviking]

Replying to WebTechGlobal:

I'm using 5 custom status for WTG Tasks Manager for a custom post type.

Posts using a custom status do not show on the All posts view - the query must still have the original core statuses coded.

Not sure if this was the original intent of this trac ticket, but I can confirm experiencing the same issue as WebTechGlobal.

register_post_status( 'active', array(
            'label'                     => _x( 'active', 'Status General Name', 'my-plugin' ),
            'label_count'               => _n_noop( 'Active (%s)',  'Active (%s)', 'my-plugin' ), 
            'public'                    => false,
            'show_in_admin_all_list'    => true,
            'show_in_admin_status_list' => true,
            'exclude_from_search'       => true,
        ) );

the show_in_admin_all_list parameter is either very misleading in its naming convention or buggy in its implementation, because setting this to true does not actually show posts of that post_status on the edit.php?post_type=custom_post screen. You have to filter the request variables and add the post statuses that way.

add_filter( 'request', 'my_request_query' );

function my_request_query( $vars ) {
    global $typenow;

    if ( 'custom_post' === $typenow ) {

        // Status
        if ( ! isset( $vars['post_status'] ) ) {
            $vars['post_status'] = array( 'my-status-1', 'my-status-2' );
        }
    }

    return $vars;
}

[Mosterd3d]

Shows the registered status when 'show_in_admin_status_list' is true

[Mosterd3d]

Fix showing "register_post_status" in save post widget. Now upper left button get updated to the selected state.

[ocean90]

138 stars and nobody wants to work on it? Ping me on Slack if you're interested in working on it for 4.6! :-)

[johnjamesjacoby]

What if we had a WP_Status base class that could be used by posts, users, comments, and maybe even taxonomy terms?

What if a status had properties to define it's object, scope, transition boundaries (to and from), related capability requirements, and so on?

What if we take the lack of an API as an opportunity to clearly define what exactly a status is, and what we need and expect from it?

Is it visibility? Is it privacy? Is it limited to certain users? Is it visible on the front end? Is it visible ever? Certain post types? When and why does it transition, and to what other possible statuses based on what conditions? Can they transition using WordPress Cron, or Heartbeat?

@danielbachhuber has worked a lot with these concepts in the past, and bbPress also implements custom post statuses. The most often used statuses are flat and simple, but imagine a post status for bbPress topics that knows to close them after 90 days in inactivity. Imagine future dated posts that actually publish on time without missing their schedules.

I absolutely do not want for perfection to get in the way of any progress that we can make here, and I think a clearer roadmap for the future of this feature will help everyone know where to focus their time and passion for solving it all.

Then maybe we can break those ideas up into smaller chunks and tickets, which I find helpful for making big issues start to feel achievable.

[colinhahn]

I'm intrigued by @johnjamesjacoby suggestion for more complicated post statuses, but I worry about whether that's feasible without a substantial rewrite of the query structure. Currently, post_status is a simple query parameter: find posts with X status. I have no idea how to construct a query for "open message boards" that dynamically close 90 days after inactivity without having to do a lot of ugly query modifications on the fly.

In my mind, post status is about visibility: who can see the post, and in what contexts (admin, frontend, REST, in a custom query for a frontend element, etc.) As far as I can tell, that framework meets the needs of almost every use case proposed in this thread, from releases to coupon codes to breaking news to moderation. The one case I don't know if it covers sufficiently is handling revisions to an already-published content that are saved in progress but don't update the original yet (see comment 115 above).

[hearvox]

I'll throw in one more use case, needed for journalist sites: Morgue. Articles with info that's out-of-date but has elements we wish to save. Often the "morgued" post's URL is redirected to a newer related article. But we still want to save the original, even if just for archival purposes.

So we set the Morgue post-status public and search parameters to false, but the show-in-lists params to true. That way we can list all Morgue posts quickly.

Not sure how general this need is, but in journalism the idea of an article morgue is central. And born-digital news is being lost FASTER than paper=printed news. So perhaps post-status can assist in archival/preservation efforts.

[Umbercode]

As I mentioned before; personally I would like this to be simple but effective:
As I see it now, there are 4 (perhaps 5) 'states:

• to-be-published
• published
• has-been-published (optionally with a 301? redirect)
• trashed
• (optional:) never-to-be-published

Implement these and give the ability to create custom names coupled to any of these states and allow those names to be shown in the UI and hooked into an action (for custom functions coupled to a named state).
Wouldn't this solve most (if not all) use-cases?

[johnjamesjacoby]

bbPress has a few custom statuses:

• Spam
• Pending
• Private
• Hidden
• Closed
• Orphaned

These are basically states that a forum/topic/reply will find themselves in based on different criteria, and a moderator can force a state if they wish.

A state is really a collection of properties, not dissimilar to how roles have capabilities, and these properties need an easy way to build database queries and limit their visibility.

Consider also that this is likely to be a solved problem already in other open source projects. Has anyone made any progress beyond WordPress when it comes to object states?

[michael.ecklund]

Just throwing my .02 here... Two of the biggest reasons I enjoy using WordPress for my website platform of choice is for the simplicity and the flexibility/customization.

I've been essentially limitless with WordPress so far. Between Custom Post Types, Custom Taxonomies, Metaboxes (backend -- only), Meta (user/post/term). Admin pages, Admin notifications, and HOOKS (let's not forget about hooks!) etc... What CAN'T you customize in WordPress?

Which brings me back to this topic and something that bugs me... It's not real simple or flexible to customize statuses in WordPress right now. I would love to see improvement in this area and would most definitely would make use of it more once improved.

I kind of like where ​@johnjamesjacoby was going with his thoughts in response #211. I do agree this area needs more thought and structure to better tie-in multiple different aspects of WordPress but also (if possible) try to keep it SIMPLE and FLEXIBLE for manipulation/customization as well.

[fjarrett]

Rather than patching a 6-year old custom status API that was never fully completed, I'm more inclined to see the @johnjamesjacoby WP_Status object dream come true.

I'd be very excited to contribute and collaborate on this.

The before-publish state is aligned with the "try-before-you-buy" direction that the Customizer and other initiatives within core have been aiming for. Providing a mechanism in which other objects can transition from before-publish to publish would allow virtually anything to be staged and previewed before going live.

Imagine being able to create draft placeholder Users or Terms that are inactive/unpublished until a certain date.

The "after-publish" state has been an itch needing to be scratched for a while, which is why I released a feature plugin for it last year. Lots of hacky nonsense was needed to pull it off in a way that maintained a consistent UX with existing post transitioning flows.

​https://wordpress.org/plugins/archived-post-status/

[dshanske]

I would be interested in a status for deleted that would return a themeable 410 or 451 page. I think that fits in with a Lot of the other use cases.

[MikeSchinkel]

Replying to johnjamesjacoby:

bbPress has a few custom statuses:
...
These are basically states that a forum/topic/reply will find themselves in based on different criteria, and a moderator can force a state if they wish.

A state is really a collection of properties, not dissimilar to how roles have capabilities, and these properties need an easy way to build database queries and limit their visibility.

Agreed.

Several solutions come to mind:

1. Implement like Roles & Capabilities via the wp_options table -- Doing it this way will force rigid states to roles -- not a good thin IMO -- and requires writing to the DB so should be done on a plugin activation, which does not work well for Git-based auto-deployments.
2. Implement them using a register_post_state() function that streamlines and simplifies add custom states since they would not need to be stored in the database, but this is also rigid.
3. Add a built-in 'post_states' taxonomy listing statuses and their respective states as child terms. This would allow users to be able to select a status for a post, or alternatively drill down and select just specific states for a post. The downside is that this is harder to specify in code because we need to make sure the statues and states are written to the taxonomy so should be done on a plugin activation, which does not work well for Git-based auto-deployments.
4. Do #2 but store the states in postmeta fields with a key format maybe like '_states:publish:is_public' and a value of 1, and allowing the users to specify individual states per post as in #3.

Seems like what is needed for this would be a good list of use-cases in a central place (Google Sheet?) and both their statuses and respective states?

[Mosterd3d]

Please check my patch "12706.5.patch", which fixes exactly all the points mentioned in the description of this ticket.

As @ocean90 wrote "138 stars and nobody wants to work on it?" please review this patch and hopefully can be shipped with 4.6 after 6 years. ;p

Let's stop this "outside the lines" discussion and close this ticket.

[djdrumn]

Replying to Mosterd3d:

Please check my patch "12706.5.patch", which fixes exactly all the points mentioned in the description of this ticket.

As @ocean90 wrote "138 stars and nobody wants to work on it?" please review this patch and hopefully can be shipped with 4.6 after 6 years. ;p

Let's stop this "outside the lines" discussion and close this ticket.

This is awesome! Thank you very much for this, in name of the community! I am using latest stable WP version v4.5.2 and just implemented this and it works flawless! :D

Please, please make this simple changes on a next release because next time I do an update, I don't want to be changing this manually on the code for something that should be included, since it's working with no problems nor errors.

More tests are needed though!

EDIT: Sorry, not showing in "Quick edit". But it's working on everything else, while we "Edit" a post (even for custom posts) and the "filter links" on the post listing to filter "post_status" also works. Even though, I still think this should go on a next release, although it's not showing in "Quick edit".

[Mosterd3d]

Tnx for this "awesome" compliment! Yes...more testers needed please!

About the "quick edit" we can make a follow up ticket as soon this one is released. It's not developed yet, because "quick edit" isn't mentioned in this ticket. So I prefer a new ticket, otherwise you keep on developing on one ticket and everybody get lost. Besides this ticket is just a little bit younger then the "quick edit" ????, so it isn't strange nobody thought about it back in those days ????

Soo yes....again....more testers! And when this is released after more then 6 years, let's have a glass champagne with all us 144 stars!

Replying to djdrumn:

Replying to Mosterd3d:

Please check my patch "12706.5.patch", which fixes exactly all the points mentioned in the description of this ticket.

As @ocean90 wrote "138 stars and nobody wants to work on it?" please review this patch and hopefully can be shipped with 4.6 after 6 years. ;p

Let's stop this "outside the lines" discussion and close this ticket.

This is awesome! Thank you very much for this, in name of the community! I am using latest stable WP version v4.5.2 and just implemented this and it works flawless! :D

Please, please make this simple changes on a next release because next time I do an update, I don't want to be changing this manually on the code for something that should be included, since it's working with no problems nor errors.

More tests are needed though!

EDIT: Sorry, not showing in "Quick edit". But it's working on everything else, while we "Edit" a post (even for custom posts) and the "filter links" on the post listing to filter "post_status" also works. Even though, I still think this should go on a next release, although it's not showing in "Quick edit".

[jetlej]

Let it be known that there are 2 bugs with the current system for registering custom post statuses:

• Custom fields are cleared as soon as they are published IF they were scheduled to be published in the future

• (Sometimes) if you click 'Publish' on a post with a custom status, it will by default publish at the time the post status was first changed to the custom status instead of 'Immediately'

[archon810]

Wow, a 6-year-old ticket for such an important core feature. Can we hope for a resolution this year?

[netweb]

#37891 was marked as a duplicate.

[dazunj]

@netweb I didn't noticed this either, hope we can see this feature soon :)

[Mosterd3d]

I'm getting a little bit confused. The fix is here. (already for a while). This ticket is also open already for a while (>6y)! In the core sessions people are discussing about another setup, but it stays only to discussions.

Please push this patch through the pipeline. It's a small fix. People will get happy and the ticket can be closed. Discussions can go further in a new ticket for future approach. It's unacceptable to let a ticket open for so long.

[imath]

Hi,

I've been working on a plugin to make sure custom statuses can be used into the Publish Metabox (the plugin is actually replacing the Built in Metabox) and inside "Quick Edit" and "Bulk Edit" forms. Instead of adding a new patch to this ticket, i thought using a plugin can make it easier for user to test.

Here's the link to the Github repo, in case you think it can contribute to this ticket: ​https://github.com/imath/wp-statuses

[madvic]

+1
Very good job @imath
Help things along

Replying to imath:

Hi,

I've been working on a plugin to make sure custom statuses can be used into the Publish Metabox (the plugin is actually replacing the Built in Metabox) and inside "Quick Edit" and "Bulk Edit" forms. Instead of adding a new patch to this ticket, i thought using a plugin can make it easier for user to test.

Here's the link to the Github repo, in case you think it can contribute to this ticket: ​https://github.com/imath/wp-statuses

[lukecavanagh]

Patch refresh

[GaryJ]

The patch is a long way off of following WP code standards.

Also, could submit_button() be used early on in the patch?

[Mosterd3d]

Refined previous patch

[Mosterd3d]

Final local tested

[uzumymw]

8 years of ticket but still Future Release?

[ZaneMatthew]

Replying to uzumymw:

8 years of ticket but still Future Release?

Welcome to open source :) and one of the better CMS' out there, if not the best.

As you can tell, by the plethora of bugs fixed, and improved admin experiences, the project is beyond stagnant, however some tickets may lay dormant.

[maidot]

This is simply a very bad joke...

[Clorith]

Not a joke, but some times tickets lose traction and become stale. It's not always a good experience, we know, but it happens when volunteers need to focus on one thing or another.

@Mosterd3d I checked your patch out, and it does need some fixing to follow the WordPress coding standards. It also looks like it might not have been made from the development source, so a refresh from the project root would be great (the path to the changed files should ideally be recognized as /src/wp-admin/includes/meta-boxes.php for example).

[Mosterd3d]

Fix custom post status

[Mosterd3d]

@ZaneMatthew @maidot ,

@Clorith You were right. Now it's made in the trunk/src.

Please check the latest patch:

12706.9.patch

Indeed 8 years is very long. the fix is still in the patch!. Let's bundle our strengths to push this forward!

[silverstar23]

If you need a Tester. Contact me. decixnet@…

[Mosterd3d]

@silverstar23

I won't let me say that twice! Please go........do it.......we have time to catch up! ;)

We can keep in contact on ​Slack where you can find me with the same username.

[chris7148]

Would love to see this fixed! I've given up on implementing a plugin with very basic workflow - didn't realise what a can of worms i was opening! I would be very happy to assist with testing etc if I can help in any way.

[andergmartins]

Is there any chance this would be implemented in Gutenberg in the future?

[andergmartins]

-- deleted message

[millennial1]

Fingers crossed for seeing this implemented and solved in Gutenberg!

[maidot]

Replying to millennial1:

Fingers crossed for seeing this implemented and solved in Gutenberg!

Yes, let's hope so! It's time to have this finally implemented.

[skorasaurus]

Note that in the absence of an official implementation, this is leading to others (​edit-flow and ​publishPress) creating up their own solution(s) to solve compatibility with Gutenberg.

[dlh]

#46397 was marked as a duplicate.

[styledev]

Where are we with this? 10 years in the making and stalled out?

[djdrumn]

Replying to styledev:

Where are we with this? 10 years in the making and stalled out?

Just WOW! Is this some kind of guinness record? :)

[wycks]

A publishing platform with a 10 year old bug for something which is essential to publishing.

Sounds about right.

[johnbillion]

Please, before you leave yet another pointless and unconstructive comment on a ticket like this, consider whether what you're saying really needs to be said and delivered to everyone who is subscribed to this ticket.

Nothing has changed since the last comment that points out this issue is ten years old, and the one before that.

The reason this issue hasn't been fixed is because it's a far-reaching problem that isn't clearly defined and has no consensus. It's not much closer to being fixed than it was a decade ago, especially with the introduction of the REST API and block editor which means the original issues exist in more places than have been discussed here or addressed in patches.

This ticket won't go anywhere unless someone decides to own it and focus on it and better define it and push for it and collaborate with all the teams that it impacts. Sorry.

[SergeyBiryukov]

Related: #55895