Custom Menu widget can't be previewed without changing a field

[kucrut]

Steps to reproduce

1. Go to Appearance > Themes
2. Click on the Customize button of the Twenty Fourteen theme
3. Expand any widget area (let's use "Widgets: Primary Sidebar")
4. Click on Add Widget button
5. Select "Custom Menu" widget
6. The widget is not added to the widget area

I believe adding "--Select--" as the first option on the Menus dropdown should solve this, because the user will be 'forced' to make an interaction to the widget form.

[westonruter]

Yes. This is a side-effect of eliminating the Submit/Update button, and not being able to auto-submit a widget's form when it is first added, because it could result in the widget form showing an error message. So either the Custom Menu widget needs to update its rendering method to use the same default menu as is pre-selected when the form is displayed, or the menu select in the form needs to start out with an empty value (as kucrut suggests, which is probably the best approach).

[westonruter]

​https://github.com/x-team/wordpress-develop/commit/af253983e00ae602fc952c25ffda6ebde7012a4c

[westonruter]

27878.patch​ takes kucrut's suggested approach.

[seanchayes]

I tested this, using the steps provided, and found the following:

Pre-patch, when adding the Custom menu widget the menu does not appear in the Sidebar and, if you only have one Custom Menu, it will only appear if you add a title to it. If you have more than one menu available and you want the first one listed then you have to switch to another menu and then switch back to the menu you actually want.

Post-patch, indeed the addition of the --Select-- option does force the user to select the menu and that triggers the action / process to refresh the preview of the theme. If, you add a title but still leave the menu option as --Select-- no menu is added (it doesn't know which one of course).

Forcing the choice seems to work logically and practically in this circumstance.

[markjaquith]

--Select-- isn't translated, but -- Select -- is, so we should use that.

[markjaquith]

It also should have a value of 0, to match nav-menus.php.

src/wp-admin/nav-menus.php:623: <option value="0" selected="selected"><?php _e( '-- Select --' ); ?></option>

Repatching.

[markjaquith]

I like 27878.diff​. Good?

[kucrut]

Replying to markjaquith:

I like 27878.diff​. Good?

+1

[markjaquith]

In 28197:

Force users to choose a nav menu in the custom nav menu widget, for a better customizer UX

Before, they had to make a dummy change to get it to render. Now they
are made to choose a nav menu from the dropdown, which feels more
natural.

fixes #27878 for trunk. props westonruter

[markjaquith]

In 28198:

Force users to choose a nav menu in the custom nav menu widget, for a better customizer UX

Before, they had to make a dummy change to get it to render. Now they
are made to choose a nav menu from the dropdown, which feels more
natural.

Merges [28197] to the 3.9 branch.

fixes #27878. props westonruter

[nacin]

Existing string: "— Select —"

What's the esc_html() for?

[westonruter]

Replying to nacin:

What's the esc_html() for?

In esc_html( $menu->name )? Just for good measure, to prevent any possibility of the value introducing malformed markup.

[markjaquith]

In 28205:

Use '— Select —' instead of '-- Select --' for nav menus. Looks nicer.

see #27878

[markjaquith]

In 28206:

Use '— Select —' instead of '-- Select --' for nav menus widget. Looks nicer.

Partially merges [28205] to the 3.9 branch.

see #27878