Make WordPress Core

Opened 11 years ago

Closed 11 years ago

#30092 closed enhancement (fixed)

Improve the default setting of 'show_in_admin_bar'

Reported by: ipm-frommen's profile ipm-frommen Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 4.1 Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: dev-feedback
Focuses: Cc:

Description

Currently, the default setting of show_in_admin_bar is defined as true === $args->show_in_menu.

Suppose, I have the custom post types CPT_A and CPT_B, and I put the menu of the latter one below the menu of the former one ('show_in_menu' => 'edit.php?post_type=cpt_a').
Unless I also define 'show_in_admin_bar' => true, for CPT_B there won't be any _Edit post_ node in the admin bar.

This is, in my opinion, not the desired behavior.
If the default value for show_in_admin_bar were to be set with respect to the presence of show_in_menu - and not by strict comparison with it - the admin bar node in question would be made available automagically.

Diff is attached.

Attachments (1)

diff.diff (546 bytes) - added by ipm-frommen 11 years ago.

Download all attachments as: .zip

Change History (11)

@ipm-frommen
11 years ago

#1 @SergeyBiryukov
11 years ago

  • Component changed from Administration to Posts, Post Types
  • Keywords has-patch added; admin-bar edit removed

#2 @SergeyBiryukov
11 years ago

  • Type changed from defect (bug) to enhancement

#3 @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 4.1

#4 @SergeyBiryukov
11 years ago

Introduced in [18261].

#5 @SergeyBiryukov
11 years ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 30041:

When using 'show_in_menu' as a default value for 'show_in_admin_bar' in register_post_type(), cast to boolean instead of requiring a strict match.

props ipm-frommen.
fixes #30092.

#6 @nacin
11 years ago

The commit message for [30041] isn't clear on whether it was understood that this was a functionality change.

[18261] intentionally made it so it would be hidden from the admin bar in this situation, and the code comment (which wasn't changed here) tried to indicate that, though not very clearly. Basically: You'll get it in the admin bar if your post type is a top-level item. If it's buried underneath another item, then you won't see it in the admin bar. There is no "Add New" menu, it's merely a button, so I'm not sure it makes sense to make it so prominent in the toolbar. (At the same time, it could be argued it needs to be exposed somewhere, and this would be a good place for it.)

I am not sure I disagree with this change, but I wanted to be sure everyone understood what's going on here.

#7 @nacin
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#8 @ipm-frommen
11 years ago

I submitted this ticket as well as the patch because I didn't see (and still don't) any reason for a post type, which is accessible through the menu, not being accessible through the admin bar.

@nacin, do you see anything that might speak against making publicly accessible post types also accessible in the admin bar?

Last edited 11 years ago by ipm-frommen (previous) (diff)

#9 @johnbillion
11 years ago

  • Keywords dev-feedback added; has-patch removed

#10 @nacin
11 years ago

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

Adding too much of any UI anywhere means the user can't find what they're looking for. If the post type is deliberately buried within another menu, I think it's logical to think it is less important than some other post types, and does not need to be yet another post type in the toolbar.

An underlying motivation was also that putting a post type under a menu would remove the "Add New" menu, which may have been a desired aspect. That said, this was done in 3.1, prior to the creation of the create_posts cap, which was 3.5.

Note: See TracTickets for help on using tickets.