make post_submit_meta_box more generic

[themattharris]

Currently there isn't a way to modify the meta boxes which set the post status. The function post_submit_meta_box in wp-admin/includes/meta-boxes.php is a closed function with post statuses hard coded. A new post status registered using register_post_status is available to the query object and plugins but cannot be added to the post status select box in the publish meta box.

A lot of the post_submit_meta_box is hardcoded to the default post status types.

Consider the use case where you want posts to only be visible to logged in users. A custom post status selectable by the user in add/edit post could be used which is then added or excluded in the query (filtered by posts_where) depending on whether the user is logged in or not. This way core can handle the non-visible posts the way private or future posts are handled.

[scribu]

There's only one metabox that sets the post status: the post_submit_meta_box metabox and yes and it should be made more generic.

In the meantime, you can replace it with your own, using remove_meta_box() and add_meta_box().

[mikeschinkel]

+1

I definitely need this.

[johnkolbert]

Ok, I've attached a diff of what I've been working on. It's not quite done yet, but I wanted to post it for others (aka @ptahdunbar) to see if I'm headed in the right direction.

It adds two new arguments to register_post_status that allow it to be attached to a particular post, and determines if it's explicitely shown in the status drop down box.

I also added an optional extra argument to register_post_type that lets the post type explicitly declare what post types it handles. If not set, it handles all the default post types, plus those declared to it by register_post_status.

This is a pretty early version. I still need to make the meta box handle these better, but I'd like any feed back from those more knowledgeable then I.

I can post examples of usage if needed.

[scribu]

I think it's a good start. There's a lot of duplicated code in those foreach() blocks. Maybe you could combine them into a helper function.

[johnkolbert]

Yes, I agree. The helper function is on my todo list. I'll post another version in the next few days that has that plus getting the post submit box more modular based on the available post statuses.

[johnkolbert]

Ok, I'm attaching the latest diff. Here's the files I've edited:

wp-includes/post.php
wp-includes/script-loader.php
wp-admin/includes/template.php
wp-admin/includes/meta-boxes.php
wp-admin/js/post.dev.js (haven't added changes to post.js yet)

For anyone who cares, and partly for my own review, I'm going go through the changes I've made. I'm sure there will be a few bugs and some more work that needs to be done to get this working, but this is what I've got so far.

File: post.php

I added four arguments to register_post_status(): post_type, edit_cap, show_in_select_ui, & display_label

post_type: holds an array of post types that the status can be explicitly declared to. Defaults to 'false', which means its available for all post types
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 capability. Defaults to NULL
show_in_select_ui: is set to true, the status is displayed in the select boxes on edit.php and post-new.php. Defaults to false
display_label: an additional label that can be used in the select box. Defaults to label or the status name

I also created a new function: post_type_can_have_status($post_type, $status)
This function takes a post type and a status and returns trueif the status is available for that post type

I added a new argument to register_post_type(): allowed_status

allowed_status: holds an array of status names that are allowed for the registered post type. If set, only these status types will be allowed for this post type. Defaults to false, meaning it uses the default post types.

File: meta-boxes.php

I adjusted the submit box to check if the post type handles specific statuses, and only shows what is appropriate. The status dropdown now shows statuses that have either assigned to the post type or the default statuses. May need some tweaking.

File: template.php

Added a helper function output_post_status_select(), which echos the available post types as option values for the select boxes.

Modified the inline editor of inline_edit_row() to use the helper function

File: script-loader.php & post.dev.js

Altered the javascript to handle the new post types. Still needs some work

[johnkolbert]

Second version DIFF file

[kevinB]

The current diff does not support a type-specific edit_cap. Why not define the custom edit_cap as a new element of the $post_type_object->cap array instead?

I'd also prefer $post_type_object->statuses rather than $status_object->post_type.

A more debatable distinction would be type-specific values for the show_in_select_ui and display_label properties. To me they do belong in the status object. You could make them array properties keyed by post type.

[mikeschinkel]

Related: #12706

[nacin]

To future release with #12706.

[soficgr]

This is something we really need ! I took a quick look in the code.

My option & how i do this with custom code for wp cms mode (sorry if I'm a little off)

We have :

• register_post_status so plugin can register new status also we have get_post_stati
• register_post_type so plugin can add new types, and also we can add supports for new status if want as feature.
• Already exist add_post_type_support (), remove_post_type_support() and many other function
• we can add capabilities when we register_post_type. Everything is fine.

But the post_submit_meta_box does not support custom status and this is the problem. Also has no hook so we can't do whatever we want without custom sumbit meta box.

Edit :I just put all type support status as support feature and manage as feature with custom sumbit meta box.

[helen]

#25279 was marked as a duplicate.

[ragulka]

My ticket on the same topic was just closed so I will attach my patch here, just in case you find it useful.

[ragulka]

Patch from duplicate ticket

[johnbillion]

Related: #24669

[DrewAPicture]

#21599 was marked as a duplicate.

[drozdz]

Any time soon? (It was scheduled for 3.6... :( )