Making WordPress.org

Opened 5 years ago

Last modified 3 years ago

#4469 reviewing enhancement

Plugin information API: Prioritize 100% matched slug in search

Reported by: tobifjellner's profile tobifjellner Owned by: tellyworth's profile tellyworth
Milestone: Improved Search 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 5 years ago.

Download all attachments as: .zip

Change History (13)

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


5 years ago

#3 @tellyworth
5 years ago

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

#4 @dd32
5 years 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
5 years 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
5 years 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
5 years 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
5 years ago

In 9042:

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

Fixes #4604. See #4469.

#9 @gibrown
5 years 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
5 years 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..

#11 @gibrown
3 years ago

  • Milestone set to Improved Search

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


3 years ago

Note: See TracTickets for help on using tickets.