#24137 closed defect (bug) (fixed)
CPT as a submenu item does not get the correct classes when adding new
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.5.1 |
Component: | Posts, Post Types | Keywords: | has-patch wcorl needs-testing |
Focuses: | administration | Cc: |
Description (last modified by )
When registering a post type as a submenu of another post type, the submenu item does not get high lighted correctly when adding a new item to the post type (the one that is a sub menu).
The post.php and edit.php screens work fine for the submenu post type; it is only post-new.php does that doesn't highlight correctly.
This is similar to #19125 and #22022, but not quite the same.
I think I've tracked the issue down to get_plugin_page_hookname()
and the $_registered_pages
global.
The submenu post type key in $_registered_pages
is (for example)
download_page_edit?post_type=edd_volume_discount
but the one retrieved by get_plugin_page_hookname( "post-new.php?post_type=$post_type", $post_type_object->show_in_menu )
is
download_page_post-new?post_type=edd_volume_discount
.
It appears the $_registered_pages
global doesn't include (at least for submenu CPTs) post-new
, only edit
.
Attachments (2)
Change History (17)
#6
@
11 years ago
So, because there is Add New access from the sub-CPT's Edit page, there's no need for an Add New menu item. But because there isn't one, it falls back to the parent. When it should first attempt to look for an Edit page for the CPT being considered.
I see a potential logic problem in this patch. Updating.
#8
follow-up:
↓ 9
@
11 years ago
I tested this at the WC Orlando contributor day and the patch wasn't needed. The steps to reproduce could benefit from some code. :-)
<?php add_action( 'admin_menu', function() { add_menu_page( 'Top Level', 'Top Level', 'manage_options', 'top-level', function() { echo 'Top level.'; } ); }); add_action( 'init', function() { register_post_type( 'book', array( 'show_ui' => true, 'show_in_menu' => 'top-level', ) ); } );
get_admin_page_parent() properly updates the parent to allow this to work. The code I was showed used 'show_ui' => false, which hides the menu (technically leaving the page still accessible, which is either a bug or an easter egg), and then add_submenu_page(). I don't think we should account for that with this patch here, especially since show_in_menu has existed since 3.1 (show_ui was 3.0).
#9
in reply to:
↑ 8
@
11 years ago
Replying to nacin:
I tested this at the WC Orlando contributor day and the patch wasn't needed. The steps to reproduce could benefit from some code. :-)
<?php add_action( 'admin_menu', function() { add_menu_page( 'Top Level', 'Top Level', 'manage_options', 'top-level', function() { echo 'Top level.'; } ); }); add_action( 'init', function() { register_post_type( 'book', array( 'show_ui' => true, 'show_in_menu' => 'top-level', ) ); } );get_admin_page_parent() properly updates the parent to allow this to work. The code I was showed used 'show_ui' => false, which hides the menu (technically leaving the page still accessible, which is either a bug or an easter egg), and then add_submenu_page(). I don't think we should account for that with this patch here, especially since show_in_menu has existed since 3.1 (show_ui was 3.0).
That's actually a different issue.
Here are the steps to replicate this issue:
- Register a top-level post type
- Register a second post type that is set to a submenu of the post type registered in 1
- Go to the child post type
- Click "Add New" for the child post type
- The parent post type All items submenu will be highlighted instead of the submenu item of the child post type
To replicate:
24137.patch seems to fix it.