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

[paulwilde]

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.

[designsimply]

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.

[paulwilde]

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.

[knutsp]

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

[celloexpressions]

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.

[celloexpressions]

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.

[afercia]

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

[paulwilde]

How do I make myself the owner of a ticket?

I'd like to tackle this for 4.4.

[adamsilverstein]

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.

[westonruter]

#34922 was marked as a duplicate.

[westonruter]

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: ​https://wordpress.slack.com/archives/core-customize/p1449592641000150

[westonruter]

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

[paulwilde]

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.

[westonruter]

@mattgeri has volunteered to write up a patch.

[westonruter]

(Reporter vs assignee personal fail.)

[westonruter]

Work being done by @mattgeri can be found at ​https://github.com/xwp/wordpress-develop/pull/137

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/137

[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

[celloexpressions]

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.

[westonruter]

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.

[westonruter]

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|$)/ );

[westonruter]

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.