WordPress.org

Making WordPress.org

Opened 3 months ago

Last modified 6 weeks ago

#4469 reviewing enhancement

Plugin information API: Prioritize 100% matched slug in search

Reported by: tobifjellner Owned by: tellyworth
Milestone: Priority: normal
Component: API Keywords:
Cc:

Description

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

Attachments (1)

2019-05-22.png (53.9 KB) - added by tobifjellner 3 months ago.

Download all attachments as: .zip

Change History (11)

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


3 months ago

#3 @tellyworth
3 months ago

  • Owner set to tellyworth
  • Status changed from new to reviewing

#4 @dd32
3 months ago

In 8902:

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

See #4469.

#5 in reply to: ↑ description ; follow-up: @coffee2code
3 months ago

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.

#6 in reply to: ↑ 5 @dd32
3 months ago

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/

#7 @tobifjellner
3 months ago

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

#8 @SergeyBiryukov
6 weeks ago

In 9042:

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

Fixes #4604. See #4469.

#9 @gibrown
6 weeks ago

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

#10 @dd32
6 weeks ago

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

Note: See TracTickets for help on using tickets.