Make WordPress Core

Opened 12 years ago

Last modified 3 years ago

#19541 accepted defect (bug)

wp_admin_bar_new_content_menu does not respect menu_position

Reported by: davistobias's profile davistobias Owned by: nacin's profile nacin
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Toolbar Keywords: needs-refresh has-patch
Focuses: Cc:

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 12 years ago.
19541.diff (3.4 KB) - added by nacin 12 years ago.

Download all attachments as: .zip

Change History (14)

#1 @davistobias
12 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
12 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
12 years ago

  • Cc code@… added

#4 in reply to: ↑ 2 @davistobias
12 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
12 years ago

  • Milestone changed from 3.4 to Future Release

#6 @nacin
12 years ago

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

#7 @nacin
12 years ago

  • Milestone changed from Future Release to 3.5

@nacin
12 years ago

#8 @nacin
12 years ago

  • Keywords 3.5-early removed

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

#9 @scribu
11 years ago

The admin bar uses numeric indexes too? Great.

#10 @nacin
11 years ago

  • Milestone changed from 3.5 to Future Release

#11 @morganestes
9 years ago

  • Keywords needs-refresh added

#12 @sabernhardt
3 years ago

  • Milestone set to Future Release
Note: See TracTickets for help on using tickets.