WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 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 10 years ago.
register_post_type_submenu_arg.diff (8.8 KB) - added by ptahdunbar 10 years ago.
new_params_register_post_type.diff (3.5 KB) - added by ptahdunbar 10 years ago.

Download all attachments as: .zip

Change History (16)

#1 @scribu
10 years ago

+1, especially on the position parameter.

#2 @voyagerfan5761
10 years ago

  • Cc WordPress@… added

#3 @ptahdunbar
10 years ago

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

#4 @ptahdunbar
10 years ago

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

#5 @ptahdunbar
10 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.

#6 @ptahdunbar
10 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.

#7 @markjaquith
10 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

#8 @matthewhollett
10 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.

#9 @scribu
10 years ago

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

#10 @matthewhollett
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#11 @matthewhollett
10 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.

#12 @dd32
10 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

#13 @dd32
10 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.