WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 months ago

#36411 new defect (bug)

Missing admin menu for custom taxonomy

Reported by: jadpm Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Menus Keywords:
Focuses: Cc:
PR Number:

Description

I found an edge case that can cause that a user with the right capabilities becomes unable to manage terms on a custom taxonomy.

The scenario includes:

  • A user with an editor role.
  • A custom post type with a set of custom capabilities that the current editor can not match.
  • A custom taxonomy assigned to that custom post types with default capabilities, so editors can manage it.

Under those premises, the admin menu for the taxonomy is not generated. Note that you can access the admin page to manage terms on that custom taxonomy if you access the URL manually.

If you then register a second custom taxonomy, also assigned to the same custom post type and with default capabilities (so an editor can manage it), then a custom admin menu is generated, wit the custom post type label, and granting access to admin pages to manage both taxonomies terms.

I am attaching a minimum test case that does register the three objects, and includes comments as to how to test it.

Attachments (1)

custom-menu.php (7.7 KB) - added by jadpm 4 years ago.
Test case for broken menu generation

Download all attachments as: .zip

Change History (6)

@jadpm
4 years ago

Test case for broken menu generation

This ticket was mentioned in Slack in #core by drew. View the logs.


4 years ago

#2 @DrewAPicture
4 years ago

Wow, cool bug! Thanks for the report @jadpm.

Based on the way the administration menus are built, it's kind of easy to see how this might happen. Essentially, all possible menus and submenus are added to the array from the get go in wp-admin/menu.php, then in wp-admin/includes/menu.php, items are removed based on capability.

This was a fun one to track down. Essentially what's happening is that in wp-admin/includes/menu.php, when you have an inaccessible post type and only a single taxonomy, the taxonomy gets re-parented and then the top-level and submenu both link to the same thing, so the submenu is removed, and later the parent is also removed.

With two taxonomies, there's two submenus, so the first gets reparented with the post type label and both stay.

So we essentially need to make a decision about expected behavior here. If you can't view/edit post type items, should you be able to view the taxonomy UIs for that post type? It's basically deciding between whether to whole-sale show the menu with both taxonomies as submenus, or always hide it if the post type parent is outside your access.

#3 @johnbillion
4 years ago

Test code which shows the expected behaviour when two submenus are in place:

add_action( 'init', function() {
	register_post_type( 'foo', [
		'public'          => true,
		'show_ui'         => true,
		'capability_type' => 'do_not_allow',
	] );

	register_taxonomy( 'bar', 'foo', [
		'public'  => true,
		'show_ui' => true,
	] );

	register_taxonomy( 'baz', 'foo', [
		'public'  => true,
		'show_ui' => true,
	] );
});

#5 @chriscct7
4 years ago

  • Version trunk deleted
Note: See TracTickets for help on using tickets.