WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 5 months ago

#19541 accepted defect (bug)

wp_admin_bar_new_content_menu does not respect menu_position

Reported by: davistobias Owned by: nacin
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Toolbar Keywords: needs-refresh has-patch
Focuses: Cc:
PR Number:

Description

What is happening:

When registering a custom post type, you can specify the position in the left-hand admin menu by using 'menu_position' to move it up or down in the list.

However, the admin bar "new content" list does not use this same order, instead it will always display "Post", "Media", "Link", "Page" (in that order) before any custom post.

What should be happening:

The admin bar "new content" list should respect the menu_position attribute.

Attachments (2)

admin_bar_create_content.patch (1.8 KB) - added by davistobias 8 years ago.
19541.diff (3.4 KB) - added by nacin 7 years ago.

Download all attachments as: .zip

Change History (13)

#1 @davistobias
8 years ago

  • Keywords has-patch added

Function wp_admin_bar_new_content_menu (since 3.1.0) uses conditionals to decide whether to show certain options, but these conditional array elements disrupt the order specified by menu_position.

The function adds array elements for posts, media, links, and pages, afterward adding the custom post types. The menu positions for the core "create new" types is specified in the codex here: http://codex.wordpress.org/Function_Reference/register_post_type

The difficulty of ordering the "create new" items is increased by the fact that sorting an array on an integer key is not possible, since multiple custom posts can choose the same menu position. Normal PHP sort methods will remove duplicate keys, so an alternate approach was required.

The attached patch uses an additional array to hold the position keys, and uses array_multisort() to order them.

#2 follow-up: @nacin
8 years ago

  • Milestone changed from Awaiting Review to 3.4

I like this. array_multisort() seems a bit clever, though. Perhaps the post type shifts to a value and make the position the new key.

#3 @tar.gz
8 years ago

  • Cc code@… added

#4 in reply to: ↑ 2 @davistobias
8 years ago

Replying to nacin:

I like this. array_multisort() seems a bit clever, though. Perhaps the post type shifts to a value and make the position the new key.

Sorry for the slow response.

I am concerned about this as well, but my attempts using shifting yielded only highly complex methods, and this one seemed reasonably straightforward. I can play around a bit more, but I'm afraid any other solution will look hackish.

#5 @ryan
7 years ago

  • Milestone changed from 3.4 to Future Release

#6 @nacin
7 years ago

  • Keywords 3.5-early added
  • Owner set to nacin
  • Status changed from new to accepted

#7 @nacin
7 years ago

  • Milestone changed from Future Release to 3.5

@nacin
7 years ago

#8 @nacin
7 years ago

  • Keywords 3.5-early removed

I was thinking 19541.diff. Seems to work for me.

#9 @scribu
7 years ago

The admin bar uses numeric indexes too? Great.

#10 @nacin
7 years ago

  • Milestone changed from 3.5 to Future Release

#11 @morganestes
4 years ago

  • Keywords needs-refresh added
Note: See TracTickets for help on using tickets.