Plugin information API: Prioritize 100% matched slug in search

[tobifjellner]

A common use case:
As an administrator of one or several WordPress installations, I want to install a specific plugin from the Plugin Directory and I know its specific SLUG/URL

I go to the "Add new plugin" interface and paste the plugin slug or the plugin page URL in the "Keyword" field.

If I'm lucky, the intended plugin may be included in the search result, but perhaps not even on page 1. So I have to look through the search result and try to find it, and double-check that the plugin I found really is the one I wanted to find.

A nice long-term solution would be ​https://core.trac.wordpress.org/ticket/40475 but that takes a change in core AND an additional keyword to be served in the API.

A much simpler solution, is what's described in this ticket. This would touch only the internal parts of the API code.

In "keyword" search:
If the supplied search argument contains "/plugins/", then delete everything from the start of the string up to and including "/plugins/".
I.e. any http|https, el|br|ja|..., wordpress.org|"" we throw away.

Next: if, after deleting any trailing spaces, there are no spaces in the search argument, then check if there's any valid plugin with exactly this slug, then
include this plugin as match number 1. Next do the normal search and exclude the slug-matched from the search result (so that it doesn't) get included twice.
(We could even say that a trailing slash would be a good marker that a slug search is intended)

This way, by searching on the slug, I'll always find my intended plugin in the same, first position. (Unless some active plugin on the users installation filters the search result, of course...)

[SergeyBiryukov]

Related: #2642, #2734, #3327, #3963

[dd32]

In 8902:

Plugin Directory: Sanitize some search terms to allow better matching and more cache hits for searches.

See #4469.

[coffee2code]

Replying to tobifjellner:

Next: if, after deleting any trailing spaces, there are no spaces in the search argument, then check if there's any valid plugin with exactly this slug, then include this plugin as match number 1.

My take is that searching for a slug-like term without a hyphen (e.g. "seo") should not feature a plugin with a matching slug since it isn't clear if user is searching on a generic term or a plugin by slug. However, a slug-like term with a hyphen (e.g. "best-seo") should feature a plugin that 100% matches the slug (and is definitely a different search than "best seo").

A search for a fully-qualified Plugin Directory URL (as also proposed in the ticket) should definitely feature the associated plugin, assuming we want to support specifying a Plugin Directory URL.

[dd32]

Replying to coffee2code:

My take is that searching for a slug-like term without a hyphen (e.g. "seo") should not feature a plugin with a matching slug since it isn't clear if user is searching on a generic term or a plugin by slug. However, a slug-like term with a hyphen (e.g. "best-seo") should feature a plugin that 100% matches the slug (and is definitely a different search than "best seo").

My take is a little different - I think we should let the search engine handle it.
It already has a slug-match boost which pushes plugins much higher in the ranking, but it doesn't always put it into first position as other plugins still match the term better based on the other ranking factors.
For most plugins it seems that slug boost already works, one example of a plugin where it doesn't is debug-bar-console which is half way down page2, because it's really not the best plugin to match it (based on last-updated, reviews, support, etc. and far more plugins better matching "debug bar console")

After [8902] searching for the exact URL results in it searching for 'plugin-slug' which at least in the case of health check now results in it being in the first position: ​https://wordpress.org/plugins/search/https://wordpress.org/plugins/health-check/

[tobifjellner]

Could a search term that begins with a forward slash / be treated as a slug search that should yield only one single result?

[SergeyBiryukov]

In 9042:

Plugin Directory: When trimming off special characters from search terms, account for multibyte alphabets.

Fixes #4604. See #4469.

[gibrown]

@dd32 I don't think we need to trim off special chars at all. Let the ES analyzers handle that. Getting rid of http junk to attempt to match on a slug makes sense though.

For a full url though we probably could bypass the search completely and just return the one plugin assuming that we find it.

[dd32]

@gibrown This was also to hopefully increase the cache hits prior to being sent over the ES, at the time we were having a significant number of junk queries coming in that were causing all sorts of warnings.

It's now much more under control, but we still get 400 Query failed back from ES more than I'd like..