Make WordPress Core

Opened 9 years ago

Closed 8 years ago

#32681 closed feature request (fixed)

Shift-clicking a menu item in the website preview iframe should open it inside the customiser

Reported by: paulwilde's profile paulwilde Owned by: westonruter's profile westonruter
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.3
Component: Customize Keywords: needs-patch
Focuses: javascript Cc:


Widgets have the great (hidden) feature that if you shift-click on the widget inside the website preview iframe, the widget would then get located and expanded inside the customiser sidebar. Menus should also have this feature.

Attachments (1)

32681.0.diff (6.9 KB) - added by westonruter 8 years ago.

Download all attachments as: .zip

Change History (25)

#1 @designsimply
9 years ago

I like that idea. For now, I think the closest thing to that is that you can click the original link in the item details, but it doesn't locate & expand like you described.

#2 @paulwilde
9 years ago

That's a little different and works the opposite way in a sense.

So for a little bit of clarify in case yourself or others don't know about the hidden feature - When you hover over a widget in the live preview it will have a title which says "Shift-click to edit this widget." which then jumps directly to that widget inside the customiser regardless of where you currently are. So with the menu items if you were to shift-click on a menu item inside the live preview it would directly jump to that.

This feature is what sold me on moving from the admin to the customiser for widget management. Such a feature will prove very useful for websites that have large menus with 50+ menu items.

#3 @knutsp
9 years ago

I didn't know about the shift click. Bringing that to menus would be a killer feature.

#4 @celloexpressions
9 years ago

  • Focuses javascript added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Implementation-wise, this should be as simple as sending up an event from the preview with the requested menu item id (which can be retrieved from its <li>'s id, then focusing the corresponding customizer control object via api.control( id ).focus(), which will automatically open the menu section to that control.

This is 4.3 material if someone makes a patch soon. See widgets' implementation for inspiration.

#5 @celloexpressions
9 years ago

No chance for 4.3 now, but this would be a really nice future release enhancement if someone wants to tackle a patch. Also lays the groundwork for a more visual/intuitive UI than the somewhat-hidden shift-click approach that could be tackled further in the future.

#6 @afercia
9 years ago

See also #33251 for considerations about the discoverability of this hidden gem.

#7 follow-up: @paulwilde
9 years ago

How do I make myself the owner of a ticket?

I'd like to tackle this for 4.4.

#8 @adamsilverstein
9 years ago

  • Owner set to paulwilde
  • Status changed from new to assigned

#9 in reply to: ↑ 7 @adamsilverstein
9 years ago

I assigned to you @paulwilde. Have at it!

Replying to paulwilde:

How do I make myself the owner of a ticket?

I'd like to tackle this for 4.4.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

9 years ago

#11 @westonruter
9 years ago

#34922 was marked as a duplicate.

#12 @westonruter
9 years ago

  • Milestone changed from Future Release to 4.5

From duplicate #34922 “Focus on nav menu item control when shift+clicking (or long-press?) on a menu item in preview”:

When widgets were added to the Customizer in 3.9, there was a somewhat hidden feature whereby a user can shift+click on a widget in the preview and the corresponding control would be focused in the pane (along with expanding the panel and section). There are also highlight outlines around each widget in the preview when interacting with a widget control, and likewise when hovering over a widget in the preview the corresponding control gets an outline in the pane. These features lessen the disconnect between the controls in the pane and the elements in the preview, and they serve as a stopgap for eventual inline controls that float next to the element being modified. For more on improving the discoverability of this shift+click mechanism, see #27403.

Nav menu items would benefit a lot from having the same functionality. Shift+clicking on a nav menu item could focus on the corresponding control in the Customizer pane. This would make it _much_ faster to edit the desired menu item, since the user wouldn't have to open the menus panel, and then figure out which menu section contains the nav menu item, to then expand and then locate the nav menu item in the list.

For discussion on whether shift+click is even a desirable way to activate this feature, see:

#13 follow-up: @westonruter
9 years ago

@paulwilde Are you still planning to write a patch for this?

#14 in reply to: ↑ 13 @paulwilde
9 years ago

Replying to westonruter:

@paulwilde Are you still planning to write a patch for this?

@westonruter I was planning to do so for 4.4, but never got round to writing one. A little busy at the moment, but I'd like to tackle this at some point if no one else does. Feel free to write a patch as I probably won't get round to looking at this (among other tickets) until the new year.

Version 0, edited 9 years ago by paulwilde (next)

#15 @westonruter
9 years ago

  • Reporter changed from paulwilde to mattgeri

@mattgeri has volunteered to write up a patch.

#16 @westonruter
9 years ago

  • Owner changed from paulwilde to mattgeri

(Reporter vs assignee personal fail.)

#17 @westonruter
9 years ago

  • Reporter changed from mattgeri to paulwilde

#18 @westonruter
8 years ago

Work being done by @mattgeri can be found at

#19 @westonruter
8 years ago

  • Keywords has-patch commit added; needs-patch removed
  • Owner changed from mattgeri to westonruter

In 32681.0.diff:

  • Add ability shift-click to nav menu items in preview in order to focus on corresponding nav menu item controls in pane.
  • Add missing params.completeCallback to MenuItemControl.focus() for parity with Control.focus().

Props @MattGeri, @westonruter

#20 @celloexpressions
8 years ago

Looks good to me.

Once this is in place, we can start more seriously considering alternative UI options for this and widgets in a feature plugin.

#21 @westonruter
8 years ago

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

In 36383:

Customizer: Add shift-click on nav menu items in preview to focus on corresponding nav menu item controls in pane.

Add missing params.completeCallback to MenuItemControl.focus() for parity with Control.focus(). Also adds params to MenuItemControl.expandForm, MenuItemControl.collapseForm(), and MenuItemControl.toggleForm().

Props MattGeri, westonruter.
Fixes #32681.

#22 @westonruter
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

One thing we missed here. When a nav menu is rendered out multiple times, only the first instance will include nav menu items that have ID attributes. This is to ensure that two elements don't have the same ID in the page. The _nav_menu_item_id_use_once function does this for the nav_menu_item_id filter.

So we need to change the selector from .menu-item[id^=menu-item-] to just .menu-item, and also to look at the class name instead of the ID on the actual nav menu items, as so:

- navMenuItemParts = $( this ).attr( 'id' ).match( /^menu-item-(\d+)$/ );
+ navMenuItemParts = $( this ).attr( 'class' ).match( /(?:^|\s)menu-item-(\d+)(?:\s|$)/ );

#23 @kirasong
8 years ago

  • Keywords needs-patch added; has-patch commit removed

#24 @westonruter
8 years ago

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

In 36523:

Customize: Ensure that nav menu items can be shift-clicked to edit in secondary instances of the same nav menu.

When the same nav menu is shown multiple times on a page, only the first instance of the nav menu will include id attributes. Subsequent instances will have the id attributes omitted. However, in both cases the underlying nav menu item's post ID is available among the class names, so the post ID can be more reliably obtained from class instead of the id attribute.

Amends [36383].
Fixes #32681.

Note: See TracTickets for help on using tickets.