Customize Menus: post type archive menu items lose their labels when loading the customizer

[celloexpressions]

In 4.7, post type archive nav menu items seem to lose their labels (and possibly other fields) when opening the customizer. They are preserved in the preview initially, until the field is edited at which point the items disappear in the preview.

Confirmed that this was introduced in trunk and that the patch on #38945 does not fix it. Milestoning for 4.7 due to possible loss of user content. To reproduce:

• Add a post type archive item to a menu.
• Save & publish changes.
• Reload the customizer -> there is no label for the post type archive menu item.

[westonruter]

@celloexpressions good catch. The problem was introduced in r38618 for #38015. The clearing of the nav menu item's title is expected per this logic in wp_update_nav_menu_item() which has been around since WP 3.0:

<?php
if ( $args['menu-item-title'] == $original_title )
        $args['menu-item-title'] = '';

The shortcomings in the r38618 was that it accounted for post_type and taxonomy nav menu item types, but not post_type_archive.

Please give 38955.0.diff​ a try. The expected behavior you should see now is that the initial title/label should be supplied as a placeholder as opposed to the input value, since it is the same as the original_title.

[westonruter]

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

[westonruter]

See 38955.1.diff​ which ensures that original_title and type_label are included among nav_menu_item setting values, especially for items representing post type archives.

@celloexpressions please give it a spin please.

[celloexpressions]

Is usability better with text in the input (4.6 behavior) or a placeholder (4.7 behavior) when the menu item title matches the associated post's title?

[celloexpressions]

Confirmed 38955.1.diff​ fixes the bug reported here as well as other issues I've subsequently encountered with incorrect or missing type labels and original titles.

I had missed the placeholder change previously. I'm not sure that this makes sense from a usability perspective, but am likely biased toward the previous behavior. Let's get 38955.1.diff​ in and discuss whether we're okay with keeping the title as a placeholder in this week's design meeting (cc @karmatosed and @hugobaeta). The question is whether users would expect the current title of a menu item to be editable if it's the original title (4.6 behavior), or whether it should be displayed as a placeholder that's replaced entirely if you go to edit it (current 4.7 behavior). See the attached screencast for a demonstration.

[westonruter]

+1 on commit. Needs dev-reviewed.

[helen]

Patch seems good.

Re: the UX change - the placeholder seems more correct generally because it will come back when you clear the field - however, I could see an argument for the actual text being in the input to start with being helpful if you just want to tweak the title as opposed to typing a whole new thing out.

[westonruter]

In 39393:

Customize: Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels.

• Show default labels for nav menu item as placeholders in a control's label field instead of showing blank.
• Store empty string as label instead of copying default labels.
• Prevent labels for post type archive items from being dropped in preview.
• Also ensure that the item type label is displayed on nav menu item controls for settings that are loaded from an existing changeset.

Amends [38618].
See #38015.
Fixes #38955.

[westonruter]

In 39395:

Customize: Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels.

• Show default labels for nav menu item as placeholders in a control's label field instead of showing blank.
• Store empty string as label instead of copying default labels.
• Prevent labels for post type archive items from being dropped in preview.
• Also ensure that the item type label is displayed on nav menu item controls for settings that are loaded from an existing changeset.

Amends [38618].
See #38015.
Fixes #38955 for 4.7 branch.