[wp-trac] [WordPress Trac] #65130: Plugin search (term) in wp-admin lacks normalization, causing fragile keyword matching

[WordPress Trac]

#65130: Plugin search (term) in wp-admin lacks normalization, causing fragile
keyword matching
-------------------------+------------------------------
 Reporter:  369work      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  administration
-------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:  has-patch =>
 * focuses:   => administration
 * component:  Administration => Plugins
 * version:  trunk =>


Old description:

> == Problem ==
>
> The plugin search box in wp-admin (`Plugins > Add New`) produces
> unreliable results when searching by keyword (term). A user searching for
> "WP Multibyte Patch" gets very different results depending on minor
> variations in their query:
>
> | Query         | Result      |
> |---------------|-------------|
> | `multibyte`   | Found       |
> | `multi byte`  | Not found   |
> | `multi`       | Not found   |
> | `multi patch` | Not found   |
>
> The root cause is that the search term is passed to the WordPress.org
> Plugin API with no normalization whatsoever.
>
> == Root cause (confirmed in source) ==
>
> In `wp-admin/includes/class-wp-plugin-install-list-table.php`, the
> `prepare_items()` method handles the search tab as follows:
>
> {{{
> // Line 161-169
> $type = isset( $_REQUEST['type'] ) ? wp_unslash( $_REQUEST['type'] ) :
> 'term';
> $term = isset( $_REQUEST['s'] )    ? wp_unslash( $_REQUEST['s'] )    :
> '';
>
> switch ( $type ) {
>     case 'tag':
>         $args['tag'] = sanitize_title_with_dashes( $term ); // sanitized
>         break;
>     case 'term':
>         $args['search'] = $term; // ← NO processing at all
>         break;
>     case 'author':
>         $args['author'] = $term; // no processing
>         break;
> }
> }}}
>
> Note the inconsistency: the `tag` type applies
> `sanitize_title_with_dashes()`, which strips spaces and normalizes the
> string, while `term` (keyword search) receives NO processing. This
> asymmetry appears unintentional.
>
> The raw `$args` is then passed directly to `plugins_api( 'query_plugins',
> $args )`, which forwards the search string as-is to
> `https://api.wordpress.org/plugins/info/1.2/`.
>
> == Proposed fix ==
>
> The fix is a single line change in `class-wp-plugin-install-list-
> table.php`:
>
> {{{
> // Before (line 169):
> $args['search'] = $term;
>
> // After:
> $args['search'] = preg_replace( '/\s+/', '', $term );
> }}}
>
> This strips whitespace between words before sending the query to the API,
> so "multi byte" becomes "multibyte" — matching the plugin slug and name
> as indexed by WordPress.org.
>
> A more robust approach could also apply `sanitize_text_field()` for
> consistency with the `tag` type, and potentially send a secondary query
> with the original term to merge results.
>
> == Files affected ==
>
> * `wp-admin/includes/class-wp-plugin-install-list-table.php` — line 169
> (primary fix)
> * `wp-admin/includes/plugin-install.php` — `plugins_api()` (no change
> needed; normalization should happen before this call)
>
> == Note on server-side improvements ==
>
> Deeper fuzzy search improvements (stemming, partial matching, relevance
> ranking) would require changes on the Meta/Plugin Directory side
> (`api.wordpress.org`). This ticket focuses solely on the low-risk, one-
> line client-side normalization that can ship independently.

New description:

 == Problem ==

 The plugin search box in wp-admin (`Plugins > Add New`) produces
 unreliable results when searching by keyword (term). A user searching for
 "WP Multibyte Patch" gets very different results depending on minor
 variations in their query:

 ||= Query       =||= Result   =||
 || `multibyte`   || Found      ||
 || `multi byte`  || Not found  ||
 || `multi`       || Not found  ||
 || `multi patch` || Not found  ||

 The root cause is that the search term is passed to the WordPress.org
 Plugin API with no normalization whatsoever.

 == Root cause (confirmed in source) ==

 In `wp-admin/includes/class-wp-plugin-install-list-table.php`, the
 `prepare_items()` method handles the search tab as follows:

 {{{
 // Line 161-169
 $type = isset( $_REQUEST['type'] ) ? wp_unslash( $_REQUEST['type'] ) :
 'term';
 $term = isset( $_REQUEST['s'] )    ? wp_unslash( $_REQUEST['s'] )    : '';

 switch ( $type ) {
     case 'tag':
         $args['tag'] = sanitize_title_with_dashes( $term ); // sanitized
         break;
     case 'term':
         $args['search'] = $term; // ← NO processing at all
         break;
     case 'author':
         $args['author'] = $term; // no processing
         break;
 }
 }}}

 Note the inconsistency: the `tag` type applies
 `sanitize_title_with_dashes()`, which strips spaces and normalizes the
 string, while `term` (keyword search) receives NO processing. This
 asymmetry appears unintentional.

 The raw `$args` is then passed directly to `plugins_api( 'query_plugins',
 $args )`, which forwards the search string as-is to
 `https://api.wordpress.org/plugins/info/1.2/`.

 == Proposed fix ==

 The fix is a single line change in `class-wp-plugin-install-list-
 table.php`:

 {{{
 // Before (line 169):
 $args['search'] = $term;

 // After:
 $args['search'] = preg_replace( '/\s+/', '', $term );
 }}}

 This strips whitespace between words before sending the query to the API,
 so "multi byte" becomes "multibyte" — matching the plugin slug and name as
 indexed by WordPress.org.

 A more robust approach could also apply `sanitize_text_field()` for
 consistency with the `tag` type, and potentially send a secondary query
 with the original term to merge results.

 == Files affected ==

 * `wp-admin/includes/class-wp-plugin-install-list-table.php` — line 169
 (primary fix)
 * `wp-admin/includes/plugin-install.php` — `plugins_api()` (no change
 needed; normalization should happen before this call)

 == Note on server-side improvements ==

 Deeper fuzzy search improvements (stemming, partial matching, relevance
 ranking) would require changes on the Meta/Plugin Directory side
 (`api.wordpress.org`). This ticket focuses solely on the low-risk, one-
 line client-side normalization that can ship independently.

--

Comment:

 65130.diff would introduce a new problem with some queries that work
 correctly now. If someone enters multiple words of the plugin name, the
 edited keyword search query could yield zero results.
 - "wp multibyte patch"
 - "wp multibyte"
 - "multibyte patch"

 I expect that keyword search queries for other plugins' names would have
 similar problems with the patch.

 In the case of WP Multibyte Patch, the plugin has more than one million
 installations. Many people successfully find it (possibly because more
 people would search for it in Japanese than in English).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65130#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform