Customize: widgets search shouldn't search by widgets id

[afercia]

Noticed while reviewing #28888.

When searching for available widgets in the Customiser, the search checks for matches in the widgets name, id, and description: https://core.trac.wordpress.org/browser/trunk/src/js/_enqueues/wp/customize/widgets.js?rev=44539&marks=101#L87

See [27650].

However, the widget ID isn't necessarily a good place where to search for a match:

• IDs may change at any time
• IDs are not supposed to have a meaning for humans
• custom widgets added by plugins are not guaranteed to have meaningful IDs
• the IDs of all the new media widgets contain the term "media", which can produce unexpected search results
• more importantly, IDs can't be translated

A couple examples in the screenshot below:

On the left: When searching for the term "med", all the 4 media widgets are returned in the search results. However, only the "Video" widget has some visible text that contains the term "med". This is confusing for users, as it's not so clear why "med" returns also the Audio, Gallery, and Image widgets.

This happens because under the hood the search is made against the following strings:

Audio media_audio-1 Displays an audio player.
Gallery media_gallery-3 Displays an image gallery.
Image media_image-3 Displays an image.
Video media_video-1 Displays a video from the media library or from YouTube, Vimeo, or another provider.

On the right: When the admin interface is set to a language other than English, the search will still match the IDs and, of course, they're in English. For example, when the admin language is German, searching for "im" returns also the "Bild" widget, which doesn't have any visible text matching "im". This is only an example: the amount of potentially confusing cases is endless, considering all the available languages.

Suggest: remove the widgets ID from the search "haystack".

[dlh]

I'm not sure a widget ID could be changed without backwards-compatibility considerations, but the given reasons generally make sense to me. The IDs-can't-be-translated screenshots seem persuasive by themselves.

However, there's similar code in place for searching themes, which also considers the theme slug, or id. The slug support was added quite deliberately in #26730.

I don't have the context to say whether ID support was added to widgets for parity with theme searches. But I could see an argument that site owners are somewhat more likely to come into contact with a theme slug than with the ID of a widget in the codebase, and so including IDs makes sense in one case but not the other.

46456.diff​ is in that spirit. Perhaps a decision could be made on this suggestion for 5.4?

[audrasjb]

Hi,

With 5.4 Beta 3 approaching and the Beta period reserved for bugs introduced during the cycle, this is being moved to Future Release. If any maintainer or committer feels this should be included or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[noisysocks]

Patch works and LGTM. I agree widget IDs shouldn't be exposed to users as they're not localised.

Putting this in the 5.6 milestone but, given it's late in the 5.6 timeline, I say it's no big deal if this gets bumped to 5.7.

[SergeyBiryukov]

In 49586:

Customize: Exclude widget ID attributes from search.

Having search terms match the ID attributes leads to confusing results, specifically when the admin interface is set to a language other than English.

Follow-up to [27650].

Props afercia, dlh, noisysocks.
Fixes #46456.