[wp-trac] [WordPress Trac] #46763: Improve plugin search results with already active plugins

WordPress Trac 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
 can do."
 > 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
 not there.

 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 mailing list