Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#3327 closed defect (bug) (invalid)

Searching with exact plugin name has it on page 3 of results

Reported by: garrett-eclipse's profile garrett-eclipse Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:



I was trying to install the Revision Control plugin through WP-Admin and searching for 'Revision Control' I initially didn't find it until I stepped to page 3 of the results.

Although the plugin is 2 years old it does at a high active install count and rating so would expect to see at the top of the first page.

It was mentioned it may also be that the support count is currently zero as the last ticket was created 5 months ago.

Let me know if I can supply anymore information.

Attachments (2)

Screen Shot 2017-12-12 at 10.15.11 AM.png (282.8 KB) - added by garrett-eclipse 6 years ago.
Search for Revision Control
Search Results for “Debug Bar Super Globals” — WordPress Plugins.png (227.8 KB) - added by mindmantra 6 years ago.
Search Results showing results not even related to searched terms

Download all attachments as: .zip

Change History (19)

6 years ago

Search for Revision Control

This ticket was mentioned in Slack in #meta by garrett-eclipse. View the logs.

6 years ago

#2 @magicroundabout
6 years ago

Same issue for me. I was trying to install "WP Help" from

Here's the scenario: I know the exact name of the plugin. I want to install it into WordPress through the Dashboard.

Here's what should happen: Because I know the exact name of the plugin, I should be able to type it in and have it display as the first result.

Here's what actually happened:

  • I typed "WP Help" into the search box.
  • Loads of stuff came up, none of which were Mark Jaquith's plugin
  • I scrolled through a few pages before getting frustrated and trying to come up with another plan.
  • I see the tabs: "Search Results | Featured | Popular | Recommended | Favourites" - none of them are any good
  • I THINK the plugin slug is "wp-help" so I search for that. Still can't find it.
  • I go to and try the same search there. Nothing helpful.
  • At this point I'm thinking that the plugin has been removed from - OH NO!!
  • As a last ditch attempt, I try using the slug to generate a URL that might show me the plugin - I type into my browser
  • Hooray! It's there.
  • So how the heck to I get a plugin that I know exists, that I know works, that I know the slug/URL of into my WP install without doing download/upload?
  • Back in my WP dashboard, I notice the dropdown by the search: "Keyword | Author | Tag" - AH! AUTHOR! I KNOW THE AUTHOR.
  • I select "Author" and type "jaquith" - there's gotta only be one jaquith, right?
  • "No plugins found"
  • Maybe it doing a "query*" search rather than a "*query*" search. I try searching for "Mark"
  • "No plugins found"
  • Seriously? There are no plugins in the repo written by anyone with the name Mark? Wow!
  • OK - favourites. Let's try that.
  • Back to - I click the heart icon to favourite
  • Back in my WP dashboard I click "Favourites" and enter my username
  • Yay! The plugin appears and I can install and activate it.

WOW! That was REALLY hard work. I'm an advanced user. This is not how it should be.


  1. A search match on an exact, or at least case-insensitive match, plugin name from either the WP Dashboard or on should show the exact match first in the list
  2. If that's not reasonable, then can an "exact name search" option be provided?
  3. If that's not possible, then can an exact slug match work?
  4. Author search needs fixing. It seems to work on username and doesn't work on a partial. Searching for "markjaquith" got me results, but not "Mark" or "Jaquith". Can we search name as well as username? There is no easy way to discover a plugin author's username.
  5. It's possible that the WP dashboard excludes plugins that don't state compatibility with your WP version. If this is the case, can a button/link be added that says "Show incompatible plugins" so that a) people know incompatible plugins exist and aren't being shown, and b) people can view them if they want to?

I found this frustrating as an advanced user. I work with clients who have sites. If I was giving instructions on installing a plugin over the phone this would have been a nightmare and probably wouldn't have been solved.

Happy to help work on solutions.

Last edited 6 years ago by magicroundabout (previous) (diff)

#3 @tellyworth
6 years ago

Both of these plugins are not showing at or near the top for the same reason: they don't have the Tested up to: header set.

Setting that to a recent WordPress version (after testing of course!) should restore the expected behaviour.

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

6 years ago

#5 @Otto42
6 years ago

  • Resolution set to invalid
  • Status changed from new to closed

As expected, setting a valid tested up to line in Revision Control bumps it to the number one result for that search.

As for the other one, yes, exact matches don't always go to the top of the search results because we tried that before, and it didn't work very well. They do get a boost from the exact name match, but the truth is that kind of thing is simply too easy to exploit, and plugin authors go nuts trying to exploit it and game the SEO in the directory.

If a plugin doesn't have proper headers, and it hasn't been updated in a while, then it should be harder to find, and it should not come up number one in search results. Plugin authors need to be active and maintain their plugins, or those plugins should drop out of search over time.

If you have a list of plugins that you use on a regular basis, then use the Favorites functionality so that you can bookmark and find them in a much easier way.

#6 @magicroundabout
6 years ago

Hmm...I'm not convinced that nothing should be done here.

I hear all the arguments for not wanting to surface older plugins to people who aren't looking for them. But there's still this specific case of knowing which plugin you want to install, and not being able to find or install it.

The favourites feature is pretty esoteric, and represents a very difficult way to achieve the user's goal. And it won't help a user that, say, has come across a plugin in a blog post or in an old WordCamp talk or something, and wants to install it. WordPress should at the very least inform the user about the state of the plugin and give the user the option to do something with it, should it not? Hiding it from the user with no explanation seems really unhelpful.

I'd also appreciate a comment on the author search - happy for this to be a separate ticket if it needs to.

This ticket was mentioned in Slack in #meta by garrett-eclipse. View the logs.

6 years ago

#8 @gibrown
6 years ago

I've adjusted the indexing so that the minimum tested value is now ($latest_wp_version - 1.0) instead of just being 1.0. So plugins that don't have it set won't be penalized quite as much. Practically speaking, this moved wp-help from who-knows-where to the second page of results when searching for (the pretty generic) "wp help". We can try that out and see how it goes.

@magicroundabout can you create a separate issue for the author search. I would think you would get some results, but apparently not. I think I looked at this when first working on the search alg and a lot of the data at the time for indexing authors was not very clean. Not sure if it has gotten better.

I agree it is a worthwhile use case, probably not the highest priority, but I can give it another shot the next time I do some reworking of the alg/indexing.

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

6 years ago

#10 @mindmantra
6 years ago

Recently I came across similar situation for

I totally understand points made in ticket:3327#comment:5.

But it seems there is same weightage applied for normal keyword based and exact name searches. If a search can be determined as exact name search then shouldn't be weightage tweaked to find if an exact match should be ranked above all or not?

We could include additional criteria for this such as install base, review average; or, to be stricter, installs & reviews in lets say last two major releases?

This needs more thought though. This is an issue worth to look at.

#11 @Otto42
6 years ago

@mindmantra A plugin that has not been updated in 6 years and which is 17 major versions behind probably should not be at the top of any search query, realistically.

6 years ago

Search Results showing results not even related to searched terms

#12 @mindmantra
6 years ago

@Otto42 You are right. But not every plugin needs to get updated to be compatible. Still, I do concur with you on keeping it in check.

My point above, is more in terms of the general issue and not specific to single plugin. I am suggesting that we take in consideration of the recent installs and reviews at least in such edge cases.

My reason being that not every plugin, such as one mentioned above, needs to be updated for every release. And with recent install base and/or reviews avg would indicate that it is working for people. Not saying that this is definitive answer but if good thought is put in it then overall search experience would be better for all.

Another issue, which probably should be a separate ticket, is that the results which are shown are not at all relavant to keywords. Even the plugins in the results have no logical relavance to each other.See attachement above.

#13 @Otto42
6 years ago

If you search for the exact phrase "Debug Bar Super Globals" then the plugin you're looking for here is on the second page of results.

Okay, yes, it's not at the top, but like I said earlier, it probably should not be at the top. It is still listed and available though.

#14 @danieltj
6 years ago

Is there a way the search query can be 'slugified'? In @magicroundabout case, he mentioned searching for 'WP Help'. That's quite an easy example where you could change that into a slug, so wp-help and then try and match plugin slugs first perhaps? Or give more weight to exact matches?

I myself try and search for my own plugins and decided to just favourite them as it's easier using the favourites tab instead because Unlist My Post (an exact match for the plugin title) doesn't seem to appear high enough when unrelated plugins seems to appear. I think the slug searches would go along way to helping sort this issue.

#15 @magicroundabout
6 years ago

@danieltj I'd say it's massively user-unfriendly to have to have a guess at a slug in order to find and install a plugin that you know exists.

@Otto42 I actually disagree. Well, partly. If I know the name of a plugin that I want to install, I should be able to install it with little hassle or effort. Its age or declared compatibility is not always a measure of its (lack of) quality.

I totally understand why you don't want to surface these old plugins. My previous suggestion to "show incompatible/old plugins" stands. I hold that people should be able to easily find and install a plugin by name.

#16 @gibrown
6 years ago

I think what we should do here is extract exact phrase matches when the user puts quotes around their search. That would make it pretty easy to take a generic phrase like wp help and make sure that the results have the phrase "wp help" rather than just the two tokens wp and help. Currently the search only does boosting by the phrase rather than requiring an exact match.

Switching from our current forked JP Search code to the latest JP search will get us this for free and that is the plan, but we also need to customize the algorithm itself to match what we currently are doing. (in other words there is some work to do to get us there).

This ticket was mentioned in Slack in #core by sergey. View the logs.

3 years ago

Note: See TracTickets for help on using tickets.