WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 20 months ago

#22022 new defect (bug)

Can’t properly add pages of type edit.php?post_type=xxx as submenu items to arbitrary parent menus — at Initial Version

Reported by: jjharr Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: reporter-feedback
Focuses: Cc:

Description

The following code illustrates the problem.

add_menu_page(‘My Pages’, ‘My Pages’, ‘edit_posts’, ‘parentslug’, array(class, func));
add_submenu_page(‘parentslug’, ‘Settings’, ‘Settings’, ‘edit_posts’, ‘mysettings’, array(class, func));
add_submenu_page(‘parentslug’, ‘Custom Post Type’, ‘Custom Post Type’, ‘edit_posts’, ‘edit.php?post_type=xxx’);

When you click on the first submenu item, the menu stays open, displaying the submenu items as it should. When you click on the item for the custom post type, the parent menu is closed and submenu pages are not displayed.

The root of the problem is how $parent_page is handled for pages of type edit.php?post_type=xxx. In get_admin_page_parent(), $parent_file is always set to $submenu[$parent], which may cause the submenu slug to be different from $parent_file. But in _wp_menu_output, if the submenu slug and parent slug are not equal, the 'wp-has-current-submenu wp-menu-open' classes do not get added which means the menu gets displayed as being closed.

Since there are no actions called between get_admin_parent_page() and the output of the menu, the only workaround I can see is some ugly JS that fixes up the classes.

It seems like the least intrusive fix would be to just move the call to apply_filters("parent_file) in menu-header.php to after the call to get_admin_page_parent() so that $parent_file can truly be overridden. This also seems inline with the intent of the filter.

Change History (0)

Note: See TracTickets for help on using tickets.