Make WordPress Core

Opened 14 years ago

Last modified 5 years ago

#12567 new enhancement

make post_submit_meta_box more generic

Reported by: themattharris's profile themattharris Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: needs-patch editorial-flow
Focuses: Cc:

Description

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.

Attachments (2)

poststatus.diff (16.0 KB) - added by johnkolbert 14 years ago.
Second version DIFF file
post-submit-hooks.25279.diff (24.9 KB) - added by ragulka 11 years ago.
Patch from duplicate ticket

Download all attachments as: .zip

Change History (25)

#1 in reply to: ↑ description @scribu
14 years ago

  • Summary changed from a custom registered post status has no access to meta boxes to make post_submit_meta_box more generic

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().

#2 @scribu
14 years ago

  • Milestone changed from Unassigned to Future Release

#3 @mikeschinkel
14 years ago

  • Cc mikeschinkel@… added

+1

I definitely need this.

#4 @johnkolbert
14 years ago

  • Cc johnkolbert added

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.

#5 @scribu
14 years ago

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.

#6 @johnkolbert
14 years ago

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.

#7 @johnkolbert
14 years ago

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
14 years ago

Second version DIFF file

#8 @johnkolbert
14 years ago

  • Milestone changed from Future Release to 3.1

#9 @kevinB
14 years ago

  • Cc kevinB added

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.

#11 @nacin
13 years ago

  • Milestone changed from Awaiting Triage to Future Release

To future release with #12706.

#12 @ninnypants
13 years ago

  • Cc ninnypants added

#13 @goto10
13 years ago

  • Cc dromsey@… added
  • Keywords changed from post_status, register_post_status, post_submit_meta_box, metaboxes to post_status register_post_status, post_submit_meta_box, metaboxes

#14 @soficgr
11 years ago

  • Keywords changed from post_status register_post_status, post_submit_meta_box, metaboxes to post_status register_post_status post_submit_meta_box metaboxes

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.

Last edited 11 years ago by soficgr (previous) (diff)

#15 @scribu
11 years ago

  • Keywords needs-patch added; post_status register_post_status post_submit_meta_box metaboxes removed

#16 @kovshenin
11 years ago

  • Cc kovshenin added
  • Keywords editorial-flow added
  • Milestone changed from Future Release to 3.6

#17 @alex-ye
11 years ago

  • Cc nashwan.doaqan@… added

#18 @ryan
11 years ago

  • Milestone changed from 3.6 to Future Release

#19 @helen
11 years ago

#25279 was marked as a duplicate.

#20 @ragulka
11 years ago

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

@ragulka
11 years ago

Patch from duplicate ticket

#22 @DrewAPicture
9 years ago

#21599 was marked as a duplicate.

#23 @drozdz
9 years ago

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

Note: See TracTickets for help on using tickets.