WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 17 months ago

#23316 new defect (bug)

Top level admin sidebar menu items with conflicting positions bury one another

Reported by: beautomated Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version: 3.5.1
Component: Administration Keywords: dev-feedback needs-refresh 2nd-opinion
Focuses: Cc:

Description

I have now seen two separate instances where a top level admin sidebar menu item wasn't showing up when another Plugin or Theme was activated. In the most recent case, using WP 3.5.1. my Plugin was creating a top level menu item with no position specified (blank, default). When I activated my client's Theme, our Plugin sidebar item disappeared and in place came the Theme Options item. I set our Plugin to use position 70, and it came back in place of the Users top level menu item.

In the earlier case, I had a custom post type that was requesting position 20. Whenever I activated Gravity Forms, my custom post type menu item was disappearing. This was with WordPress v3.5

According to the codex page: "WARNING: if two menu items use the same position attribute, one of the items may be overwritten so that only one item displays! Risk of conflict can be reduced by using decimal instead of integer values, e.g. 63.3 instead of 63 (Note: Use quotes in code, IE '63.3')."

This seems like a bug to me. Why should items be allowed to completely overwrite one another? Shouldn't they just fall in line, albeit randomly when two conflict? I can see tons of problems with Themes and Plugins killing one another's top level menu items, and the user not understanding what's going on when they loose something unexpectedly.

Change History (5)

comment:1 @SergeyBiryukov3 years ago

I guess #12718 would solve this.

comment:2 @rmccue3 years ago

In the mean time, we could check isset( $menu[ $position] ) and increment $position until we have an empty space.

comment:3 follow-up: @nacin3 years ago

Floats can't be used as array indicies, so that warning is plain wrong anyway.

comment:4 in reply to: ↑ 3 @rmccue3 years ago

Replying to nacin:

Floats can't be used as array indicies, so that warning is plain wrong anyway.

Note the "Use quotes in code, IE '63.3'". It's using strings as the indices, then relying on type coercion in the sorting code.

comment:5 @desaiuditd17 months ago

  • Keywords dev-feedback needs-refresh 2nd-opinion added

Just to add a point; Custom Post Type Menu Positions does not allow float / string positions.
Because of the followinf code snippet in wp-admin/menu.php (Line 108)

$ptype_menu_position = is_int( $ptype_obj->menu_position ) ? $ptype_obj->menu_position : ++$_wp_last_object_menu; // If we're to use $_wp_last_object_menu, increment it first.

It forces to have an integer value otherwise it will assign ext incremented position for the custom post type menu.

Note: See TracTickets for help on using tickets.