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

[ptahdunbar]

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 :)

[scribu]

+1, especially on the position parameter.

[ptahdunbar]

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

[ptahdunbar]

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

[ptahdunbar]

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.

[ptahdunbar]

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.
  

[markjaquith]

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

[matthewhollett]

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.

[scribu]

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

[matthewhollett]

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.

[dd32]

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

[dd32]

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.