Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#16015 closed defect (bug) (fixed)

show_in_menu has some menu selection issues

Reported by: nacin's profile nacin Owned by: duck_'s profile duck_
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.1
Component: Posts, Post Types Keywords: has-patch commit
Focuses: Cc:

Description

I have an employees post type with show_in_menu set to 'users.php'. This hides the Add New menu, as expected, and nests "Employees" under Users.

post-new.php?post_type=employees doesn't trigger any item in the menu from being selected. This is expected.

However, post.php?post=100&action=edit does show the Employees submenu as selected -- but not the rest of the menu. This is unexpected. The entire menu should be selected.

(Think of it as consistent with Posts, only lacking an "Add New" submenu -- that's the responsibility of the developer.)

Attachments (2)

garyc40-16015.patch (985 bytes) - added by garyc40 14 years ago.
there's a patch for that
16015.parent-file.diff (599 bytes) - added by duck_ 14 years ago.

Download all attachments as: .zip

Change History (10)

@garyc40
14 years ago

there's a patch for that

#1 @garyc40
14 years ago

  • Keywords has-patch needs-testing added

My patch is not very elegant. It loops through the submenu items to check if $submenu_file == $sub_item[2] . This is the same check that happens way below, where 'current' class is attached to current sub-item.

I kind of dislike it, but it works.

Any idea how to fix this without having to refactor the way _wp_menu_output works?

Last edited 14 years ago by garyc40 (previous) (diff)

#2 @duck_
14 years ago

Set the $parent_file based on show_in_menu in post.php. Not tested every usage of $parent_file to test this, but all menus seem to function correctly. Note that for edit.php?post_type=bar and edit.php?post_status=foo&post_type=bar the $parent_file is set to the show_in_menu var via get_admin_parent_page().

I do think that _wp_menu_output needs to be revisited in the future, I have a patch somewhere with some optimizations but never got round to testing properly and uploading.

#3 @nacin
14 years ago

Looks good. Works for the examples I have.

#4 @nacin
14 years ago

  • Keywords commit added; needs-testing removed

#5 @nacin
14 years ago

  • Owner set to duck_
  • Status changed from new to assigned

#6 @nacin
14 years ago

To reproduce:

add_action( 'init', 'ticket_16015' );
function ticket_16015() {
	register_post_type( 'employees', array(
			'labels' => array(
					'name' => __( 'Employees' ),
					'singular_name' => __( 'Employees' ),
				),
			'public' => true,
			'show_ui' => true,
			'show_in_menu' => 'users.php',
			'has_archive' => true,
			'rewrite' => true,
			'supports' => array( 'title' ,'thumbnail', 'excerpt', 'editor', 'custom-fields' ),
	) );
}
Last edited 14 years ago by nacin (previous) (diff)

#7 @westi
14 years ago

16015.parent-file.diff looks ok and fixes the issue for me.

#8 @westi
14 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [17169]) Ensure the Parent menu is hilighted correctly when Custom Post Types are shown under an existing top level menu. Fixes #16015 props duck_.

Note: See TracTickets for help on using tickets.