Add opt-in "Plugins" stats section to author profiles (aggregate public plugin stats + sparklines)

[motylanogha]

Summary

Add an opt-in "Plugins" section to author profiles (profiles.wordpress.org), sitting alongside the existing "Recent impact" block, that aggregates a plugin author's already-public stats: total active installs, all-time downloads, plugin count, average rating, plus a per-plugin list with a small download sparkline.

Rationale

Profiles already surface a contributor's plugins as a flat list. For authors, the numbers that show their reach (active installs, downloads, rating) live one click away on each individual /plugins/<slug>/advanced/ page and are never rolled up. A profile-level roll-up gives authors and visitors an at-a-glance picture of a maintainer's footprint, in the same visual language as the existing impact tiles.

Why this is low-risk

Every figure shown is already public on each plugin's directory page. The proposal only aggregates and re-displays public data on the author's own profile, so it exposes nothing new. No committer-only or raw per-site data is involved.

Data sources (all public, no auth):

• GET /plugins/info/1.2/?action=query_plugins&request[author]=<user> gives per-plugin active_installs, downloaded, rating, num_ratings.
• GET /stats/plugin/1.0/downloads.php?slug=<slug>&limit=30 gives daily downloads for the sparkline.

Scope

• Opt-in. New profile section, off by default, so authors who do not want a stats board on their public profile are not forced into one.
• Aggregation only of already-public numbers.
• No new frontend dependency. Charts are inline SVG sparklines (matches the directory's existing lightweight approach, no Chart.js).
• Server-side fetch with a 12h transient cache to avoid load on api.wordpress.org.

Out of scope (for this ticket)

• Committer-only granular stats (raw daily counts per site, referrers).
• Historical active-install growth graph. The old stats/plugin/1.0/active-installs.php endpoint now returns "File not found", so install history would need a separate data source. Deferred.

Proof of concept

I have a working, self-contained PoC plugin that renders the exact .wp-p2-plugins markup intended to drop in beside .wp-p2-impact, driven by live API data, with a demo shortcode. It uses inline-SVG sparklines and a 12h transient cache. Rendered live for an 8-plugin author without issue. Happy to attach it or open a PR.

Open questions

1. Opt-in toggle location: profile settings, or auto-show when the user has at least one published plugin?
2. Is a per-author aggregate query acceptable load, or should it be precomputed into profile meta on a cron?
3. Include themes (query_themes) in the same block, or plugins-only first?

[motylanogha]

Two follow-ups after the initial PoC:

1. Author vs. committer coverage. The public query_plugins&request[author]=<user> filter only matches plugins where the user is the listed author of record. A user who is a committer or contributor but not the author would get an empty block. For the real profile integration the plugin list should come from Meta's internal committer relationship (the same source the profile already uses to list a user's plugins), and this public API should be used only to pull the stat numbers.

2. Profile-user resolution. Updated the PoC so the block derives the displayed user via bp_get_displayed_user_username() when no explicit argument is given, so it needs no argument inside a profile template. The shortcode user="" arg stays as an override for standalone demos. The replaced attachment reflects this.

[motylanogha]

PoC plugin (updated): now derives the profile user via bp_get_displayed_user_username() when no arg is given; user="" shortcode arg is an override. Renders .wp-p2-plugins from public plugin-directory stats + inline-SVG sparklines. GPL-2.0-or-later. Includes sparkline unit test.