[wp-trac] [WordPress Trac] #46763: Improve plugin search results with already active plugins
noreply at wordpress.org
Thu Apr 4 21:11:05 UTC 2019
#46763: Improve plugin search results with already active plugins
Reporter: joostdevalk | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Plugins | Version:
Severity: normal | Resolution:
Keywords: needs-design-feedback | Focuses: ui, administration
Comment (by ionutn):
Replying to [comment:20 gibrown]:
> > The ultimate solve here is NOT "let bigger monolithic plugins rank
higher" but "highlight for people what the plugins they're ALREADY USING
> I like it when I agree with @Ipstenu. The user has already decided on a
set of plugins. Let's not second guess that decision, let's use it. We
should boost up (or just run a second search query across only the
installed plugins) and display any already installed plugins.
> Install count, reviews, support threads all matter a lot for the search
ranking alg. But once a user has installed a plugin they have presumably
already taken those into account. (I feel some desire to go on a rant that
there is no such thing as "organic search results", but I will try to
refrain.) Once the user has decided to install a plugin, that information
seems way more important than any usage info that wp.org has knowledge of.
> I don't like only boosting the plugins that appear in the first page of
results, because what if the user has a plugin installed that is on the
second or third page? Do we display them only when the user goes to the
next page? Do we not show them differently at all? I think this gets
complicated, and also, because the search alg uses things like install
count it will definitely favor the big plugins.
> I don't love the idea of a completely separate section of search
results, but maybe we limit it to the top 3 and can have a button for
expanding to show more if there are more.
> I do think we should also show highlights of why a result matched on the
search screen, but after thinking about it some more, that should probably
be another ticket and involve a complete redesign of the search interface.
Probably also better to do that on wp.org first.
> Unfortunately, there is some performance downside with putting these
filters/boosting on the search queries. It will mean fewer cache hits on
wp.org and more having to make the extra hop to Elasticsearch. I'm not
sure if there is a way around that or how much slower it will make things.
I know anywhere not in N America is already pretty slow, so the added
marginal delay is probably minor in comparison.
Completely agree with the first part, the challenge in this particular
case is that it's not always the user choice ( get pre-installed by some
hosts), that's why the whole part of users that don't understand what
plugin does. We do have a plugin which works like jetpack, we recommended
it with themes, users got it as a recommendation, but they aren't using it
that much, because the initial intent to install a plugin like that was
I believe that users who decide to install JetPack because is an awesome
all-in-one solution backed by Automattic and would do that on purpose,
would check all the features, would learn it and would not need such hints
( there is an email sequence as well), however a person who got it because
it was pre-installed, recommended by another theme/plugin as a sort of
requirement, won't use it, that's why usage data is low for certain
features I believe. Again, I am talking just from my experience.
Ticket URL: <https://core.trac.wordpress.org/ticket/46763#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac