[wp-trac] [WordPress Trac] #22022: Can’t properly add pages of type edit.php?post_type=xxx as submenu items to arbitrary parent menus

[WordPress Trac]

#22022: Can’t properly add pages of type edit.php?post_type=xxx as submenu items to
arbitrary parent menus
----------------------------+------------------------------
 Reporter:  jjharr          |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  3.4.2
 Severity:  normal          |  Resolution:
 Keywords:                  |
----------------------------+------------------------------
Description changed by SergeyBiryukov:

Old 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.

New 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.

--

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22022#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software