WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 9 months ago

Last modified 9 months ago

#38955 closed defect (bug) (fixed)

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

Reported by: celloexpressions Owned by: westonruter
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch has-unit-tests ui-feedback commit dev-reviewed
Focuses: Cc:

Description

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.

Attachments (3)

38955.0.diff (1.7 KB) - added by westonruter 9 months ago.
38955.1.diff (12.3 KB) - added by westonruter 9 months ago.
https://github.com/xwp/wordpress-develop/pull/206
38955-placeholder-vs-text.gif (260.7 KB) - added by celloexpressions 9 months ago.
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?

Download all attachments as: .zip

Change History (13)

#1 @westonruter
9 months ago

  • Owner set to westonruter
  • Status changed from new to accepted

@westonruter
9 months ago

#2 @westonruter
9 months ago

  • Keywords has-patch needs-unit-tests added; needs-patch removed

@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.

#3 @westonruter
9 months ago

  • Keywords has-unit-tests needs-testing added; needs-unit-tests removed

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
9 months ago

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?

#4 @celloexpressions
9 months ago

  • Keywords ui-feedback commit added; needs-testing removed

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.

#5 @westonruter
9 months ago

  • Keywords dev-feedback added

+1 on commit. Needs dev-reviewed.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


9 months ago

This ticket was mentioned in Slack in #core by westonruter. View the logs.


9 months ago

#8 @helen
9 months ago

  • Keywords dev-reviewed added; dev-feedback removed

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.

#9 @westonruter
9 months ago

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

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.

#10 @westonruter
9 months ago

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.

Note: See TracTickets for help on using tickets.