![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 5 weeks ago
#8298 new enhancement
Plugin search: cap the active_installs contribution and scale the rating signal by review volume
| Reported by: | jeangalea | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Improved Search |
| Component: | Plugin Directory | Keywords: | |
| Cc: |
Description
Plugin directory search currently lets a large enough active-install count outweigh every other quality signal, including a near-1-star rating. A host that deploys its plugin to its customer base can reach the top of competitive search results within days, with no organic adoption at all. This is not hypothetical: sg-ai-studio was auto-installed by SiteGround on 1M+ customer sites in late May 2026 and currently ranks second for "ai agent" with a 1.3-star rating (59 of 64 reviews are 1-star).
I maintain plugins in the directory myself, so I have an interest here, but the numbers below are mechanical and checkable against the source.
Why the algorithm produces this
In class-plugin-search.php (GitHub mirror), the function_score combines:
active_installs: field_value_factor, factor 0.375, modifier log2pactive_installs<= 1M: exp decay correction (origin 1M, scale 900k, decay 0.75)rating: field_value_factor, factor 0.25, modifier sqrtplugin_modified: exp decay (offset 180d, scale 360d)tested: exp decaysupport_threads_resolved: field_value_factor, factor 0.25, modifier log2p
At the end, max_boost and score_mode are unset, so Elasticsearch defaults apply: all factors multiply, with no cap.
The asymmetry: installs are log-scaled but unbounded, while rating is square-rooted, which compresses the whole 1-star-to-5-star range into roughly a 2.2x spread (0.25*sqrt(1.1) ≈ 0.26 vs 0.25*sqrt(4.8) ≈ 0.55). A 1M-install plugin gets ~7.5 from the install factor alone, plus the maximum freshness factor if it is new, plus the near-1M decay bonus. The worst possible rating cannot offset that. So the directory's worst-rated plugins can sit above its best-rated ones whenever installs were acquired in bulk.
The design assumption behind weighting active_installs is that installs are a proxy for user choice. Host auto-deployment breaks that assumption: the installs measure the host's customer count, not plugin quality or adoption. WordPress.org has already acknowledged that install data is a gaming target; that was the stated rationale for removing the active install growth charts in 2022 (12097). The search ranking still treats the same number as trustworthy.
Related prior tuning of these exact weights: #4450 (sub-1M correction), #2604 (>1M scoring fix), #1692 (search quality umbrella, where the stated intent was that installs be "weighed evenly" against rating and update activity, which sqrt-vs-log2p does not achieve).
Proposal
Two small changes, both within the existing function_score:
- Cap the install contribution. Either re-introduce
max_booston the function_score, or cap the active_installs factor's output. Installs should remain a signal; they shouldn't be a signal that can't be outvoted. - Scale the rating signal by review confidence. With sqrt, ratings barely move the score. When review volume is high, the rating is high-confidence and should bite harder, in both directions. A plugin with dozens of reviews averaging near 1 star is the directory's clearest possible quality signal and is currently almost ignored.
Longer term, it's worth noting that the update-check pings give WordPress.org enough server-side data (install time-series, requesting-network concentration) to discount bulk-deployed installs specifically, without exposing any new public data. I'm not proposing that here; the two changes above are cheap, precedented, and address the immediate distortion.
Happy to put together a patch/PR against the GitHub mirror if the direction is agreeable.
