WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 7 months ago

#46456 new defect (bug)

Customize: widgets search shouldn't search by widgets id

Reported by: afercia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: has-screenshots has-patch
Focuses: ui Cc:

Description

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:

http://cldup.com/eGFM1LwArc.png

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

Attachments (1)

46456.diff (579 bytes) - added by dlh 10 months ago.

Download all attachments as: .zip

Change History (3)

@dlh
10 months ago

#1 @dlh
10 months ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 5.4

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?

#2 @audrasjb
7 months ago

  • Milestone changed from 5.4 to Future Release

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.

Note: See TracTickets for help on using tickets.