Make WordPress Core

Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#24137 closed defect (bug) (fixed)

CPT as a submenu item does not get the correct classes when adding new

Reported by: mordauk's profile mordauk Owned by: helen's profile helen
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 SergeyBiryukov)

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)

24137.patch (1015 bytes) - added by mordauk 11 years ago.
24137.2.patch (1.2 KB) - added by markjaquith 11 years ago.

Download all attachments as: .zip

Change History (17)

#1 @chriscct7
11 years ago

  • Cc chriscct7@… added

#2 @mordauk
11 years ago

  • Cc pippin@… added

#3 @SergeyBiryukov
11 years ago

  • Component changed from Menus to Post Types
  • Description modified (diff)

@mordauk
11 years ago

#4 @mordauk
11 years ago

To replicate:

  1. Register a top-level post type
  2. Register a second post type that is set to a submenu of the post type registered in 1
  3. Go to the child post type
  4. Click "Add New" for the child post type
  5. The parent post type All items submenu will be highlighted instead of the submenu item of the child post type

24137.patch seems to fix it.

#5 @mordauk
11 years ago

  • Keywords has-patch wcorl added; needs-patch removed

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

#7 @markjaquith
11 years ago

24137.2 nests the check better. We want the parent fallback to happen after we've verified there isn't a post-new.php menu item to highlight. I also added some code comments.

#8 follow-up: @nacin
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 @mordauk
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

#10 @SergeyBiryukov
10 years ago

#28287 was marked as a duplicate.

#11 @SergeyBiryukov
10 years ago

  • Focuses administration added
  • Milestone changed from Awaiting Review to 4.0

#12 @mordauk
10 years ago

  • Keywords needs-testing added

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


10 years ago

#14 @helen
10 years ago

  • Owner set to helen
  • Resolution set to fixed
  • Status changed from new to closed

In 29300:

When adding a post of a post type whose menu item is in a submenu, highlight the correct menu item. props mordauk, markjaquith. fixes #24137.

#15 @chriscct7
9 years ago

#25397 was marked as a duplicate.

Note: See TracTickets for help on using tickets.