WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12541 closed defect (bug) (fixed)

Core post types should respect the show_ui parameter in register_post_type()

Reported by: ptahdunbar Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

Currently, the Posts, Pages, and Media menu items are hardcoded. This causes an issue if a user wants to hide those post types by re-registering the post type and setting the show_ui parameter to false. They don't get removed. In addition, if they set the show_ui parameter to true, you get duplicate menu items.

This needs to be addressed. Potential issues:

The Posts, Pages, and Media menu items loss their current position in the menu if they were to get re-registered. Possible solutions would be to extend register_post_type to specific the menu position ala a position parameter like add_menu_page() or WP should add hooks to reorder them back to their original positions. I'm for extending register_post_type() so any post type can benefit. Patches welcomed :)

Attachments (3)

more_register_post_type_args.diff (7.1 KB) - added by ptahdunbar 4 years ago.
register_post_type_submenu_arg.diff (8.8 KB) - added by ptahdunbar 4 years ago.
new_params_register_post_type.diff (3.5 KB) - added by ptahdunbar 4 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 scribu4 years ago

+1, especially on the position parameter.

comment:2 voyagerfan57614 years ago

  • Cc WordPress@… added

comment:3 ptahdunbar4 years ago

Patch adds two new args to register_post_type() menu_position and menu_class.

comment:4 ptahdunbar4 years ago

That patch also breaks the media menu links. Looks like we need to make submenus customizable.

comment:5 ptahdunbar4 years ago

register_post_type_submenu_arg.diff Adds an additional 'submenu' param to register_post_type().

This is a first pass for allowing post types to have a custom submenu items with the default Media post type being a prime example.

This patch works but somehow breaks the highlighting of submenu items under the 'post' post type.

comment:6 ptahdunbar4 years ago

  • Keywords has-patch added; needs-patch removed

new_params_register_post_type.diff

Adds two new parameters:

  • menu_position - The position in the menu order the post type should appear. Defaults to the bottom.
  • menu_icon - The url to the icon to be used for this menu. Defaults to use the posts icon.

comment:7 markjaquith4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [14014]) Add menu_position and menu_icon params to register_post_type(). props ptahdunbar. fixes #12541

comment:8 matthewhollett4 years ago

Can this be reopened? The menu_position and menu_icon params are useful, but it is still not possible to override the default register_post_type arguments for Posts, for instance by setting show_ui to false, or removing supports.

comment:9 scribu4 years ago

matthewhollett: if you're sure that that's the case, go ahead.

comment:10 matthewhollett4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:11 matthewhollett4 years ago

Upon further testing, I have noticed some problems with the new 'menu_position' parameter in register_post_type(). Setting the 'menu_position' parameter when registering new post types results in new menu items replacing core menu items.

For example, registering a new post type with "'menu_position' => 5" will entirely replace "Posts" in the menu.

comment:12 dd324 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

I have noticed some problems with the new 'menu_position' parameter in register_post_type()

See: [14049] Prevent $post_type_object->menu_position from conflicting with another plugin, or core menu item. Props blepoxp. Fixes #12951

comment:13 dd324 years ago

but it is still not possible to override the default register_post_type arguments for Posts, for instance by setting show_ui to false, or removing supports.

Didnt notice this comment before.

For 3.0, No. Certain parts of the WordPress admin are hard coded, The default types are one example of that. Feel free to open a ticket for 3.1 to move the hard coded items over to the API.

Note: See TracTickets for help on using tickets.