[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:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:                  |
----------------------------+-----------------------------
 == 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.

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