Make WordPress Core

Opened 9 years ago

Closed 18 months ago

#33779 closed defect (bug) (wontfix)

Menu Customizer: Show on screen?

Reported by: pavelevap's profile pavelevap Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: close
Focuses: Cc:

Description

On Menu admin page I can use "Screen Options" Tab to enable content which will be available for adding to menu. I am not sure if it was supposed to be active also for Menus in Customizer (it could be helpfull)? But now I can see there only one checkbox related to WooCommerce.

There should be all content types available for checking or disabled for everything, I guess...

Attachments (1)

Menu_Customizer_Show_on_screen.png (64.4 KB) - added by pavelevap 9 years ago.

Download all attachments as: .zip

Change History (11)

#1 @swissspidy
9 years ago

  • Component changed from Menus to Customize
  • Keywords close added

The screen options and the customizer are completely different. If you add something to the screen options for menus, you'll need to add it to the customizer separately.

#2 @pavelevap
9 years ago

Yes, but the point is that they should not be completely different. I think that this could be consistent? Advanced menu properties are also displayed in Customizer and Menu page. I would expect that I can turn off several panels with items not usable for menus... And now they are called "Boxes" even if they are "Panels" (used across Customizer)?

#3 @wonderboymusic
8 years ago

  • Version changed from trunk to 4.3

#4 @swissspidy
8 years ago

@pavelevap Seems like I misunderstood you at first, sorry about that!

Screen options are of course shown in the customizer. I don't think it makes sense to add options to show/hide specific sections (= boxes in the admin) to the menu customizer. Because of the different UI it's simply not necessary

@westonruter What's your opinion on this?

#5 @westonruter
8 years ago

@pavelevap Are you just talking about adding custom fields to menu items in the Customizer? If so, this is not currently facilitated in Core (but needs to be). See #18584.

#6 @SergeyBiryukov
8 years ago

I think @pavelevap's report is about inconsistent UI:

  • On Menus screen, you can show and hide specific boxes in Screen Options. You can also turn on advanced menu properties like Link Target there.
  • Menu Customizer also has a Screen Options control, but you cannot show and hide specific sections there, all content types are displayed. You can only configure advanced menu properties.

#7 @voldemortensen
8 years ago

  • Keywords close removed

#8 @celloexpressions
8 years ago

This functionality was intentionally left out of the customizer version of menus for simplicity (dating back to the original menu customizer feature-plugin nearly two years ago when the other screen options were implemented). In the admin, there are discovery problems for many users for finding that they can turn on display of additional content types, and the show_in_nav_menus option when registering custom post types (and taxonomies?) can be used to turn off content types that should never be used in menus.

However, this could be added if absolutely necessary, it just seems like unnecessary UI that hides potentially-useful options that users may not be aware of. In situations where there are options that shouldn't ever be shown, the themes/plugins should be using show_in_nav-menus appropriately. The post format taxonomy in core is the only potential core thing that should be hidden, but it can be useful and is only available when the theme supports it.

#9 @celloexpressions
3 years ago

  • Keywords close added
  • Milestone set to Awaiting Review

Suggesting close as wontfix based on lack of movement and that the current behavior is a design decision as noted above. Does anyone feel strongly about adding screen options to hide post/taxonomy types from the add menu items panel?

#10 @JeffPaul
18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I concur, let's close as wontfix.

Note: See TracTickets for help on using tickets.