Stats: add self-hosted admin bar link

[dognose24]

Part of STATS-287.

Proposed changes

• Add a Stats link under the site-name admin bar menu for self-hosted Jetpack sites.
• Gate the link to users with the view_stats capability.
• Skip WordPress.com platform sites so the existing jetpack-mu-wpcom admin bar link remains responsible there.
• Add PHPUnit coverage for the admin bar link behavior and a Jetpack plugin changelog entry.

Related product discussion/links

• pgvZfX-Qh-p2#comment-753.

Does this pull request change what data or activity we track or use?

No.

Testing instructions

• Check out this branch on a self-hosted Jetpack test site with the Stats module active.
• Log in as a user who can view Stats.
• Open any front-end page and hover the site name in the admin bar.
• Confirm a Stats link appears under Dashboard and points to /wp-admin/admin.php?page=stats.
• Open WP Admin and hover the site name in the admin bar.
• Confirm the Stats link does not appear there, where core shows Visit Site instead of Dashboard.
• Confirm the existing top-level Stats sparkline remains unchanged when the small chart setting is enabled.
• Confirm users without the view_stats capability do not see the Stats link.

Before	After

Automated testing:

• php -l projects/plugins/jetpack/modules/stats.php
• php -l projects/plugins/jetpack/tests/php/modules/stats/Stats_Admin_Bar_Test.php
• xmllint --noout projects/plugins/jetpack/phpunit.9.xml.dist projects/plugins/jetpack/phpunit.11.xml.dist
• git diff --check

Not run:

• pnpm jetpack docker phpunit jetpack --name statslink --php 8.3 -- --filter=Stats_Admin_Bar_Test - local Docker test environment issue.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

---

Jetpack plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[kangzj]

Review depth: thorough (auto-upgraded — diff adds a current_user_can() check)

Summary

Adds a Stats link to the site-name admin bar submenu for self-hosted sites, gated behind view_stats and skipped on WP.com platform sites. Small, well-contained, additive change.

Testing performed

• End-to-end in a local self-hosted Jetpack docker env (logged in as an administrator with Stats active):
  • Front end, site-name dropdown → Stats appears alongside Dashboard, href resolves to admin.php?page=stats. ✅ matches PR screenshots.
  • wp-admin, site-name dropdown → only Visit Site/Visit Store present, no Stats link (core shows Visit Site there instead of Dashboard, and the code correctly uses the absence of the dashboard node as its front-end proxy — verified this matches wp_admin_bar_site_menu() in WP core). ✅
  • Capability gate verified directly: current_user_can('view_stats') is true for an administrator and false for a subscriber on this install, matching the new PHPUnit coverage. ✅
  • Confirmed the pre-existing stats_admin_bar_menu() sparkline (different hook, different node id) is untouched by this diff — no interaction risk.
• Unit tests: ran Stats_Admin_Bar_Test locally (PHP 8.3) — OK (4 tests, 8 assertions). All 4 scenarios (capability granted/denied, dashboard node present/absent, WP.com platform) pass.
• CI: all PHP lint (7.2–8.5), PHPUnit matrix, JS tests, and coverage checks are green on the PR.

Code review

• Logic correctly mirrors WP core's own frontend-detection approach (checking for the dashboard node) rather than reinventing it — robust if core's conditions change.
• Host::is_wpcom_platform() and the view_stats capability check are the right primitives; automattic/jetpack-status is already a declared dependency of the plugin, no version-skew concern.
• Output is safe: title is a translated static string, href comes from admin_url() — no unescaped user input.
• Changelog entry is well-formed (patch/enhancement, imperative, punctuated).
• Test coverage is solid: covers grant/deny, dashboard-node presence, and WP.com platform exclusion, using existing test conventions in the codebase (Constants, Status\Cache, WP_UnitTestCase_Fix).

Verdict

Looks good — approving.

[kangzj]

Non-blocking follow-up thought (not asking for changes here — happy to ship this as-is and iterate):

This gates on Host::is_wpcom_platform(), which covers both Simple (is_wpcom_simple()) and Atomic/WoA (is_woa_site()). That means Atomic currently gets its Stats admin-bar link exclusively from jetpack-mu-wpcom's wpcom_add_stats_to_site_menu() (added in #50222), not from this plugin.

Atomic sites run the actual Jetpack plugin (that's what is_woa_site() itself checks for — Atomic markers + wpcomsh on top of a real Jetpack install), so architecturally this module's own implementation is arguably the more natural owner for Atomic, with jetpack-mu-wpcom staying scoped to Simple only (where there's no standalone Jetpack plugin instance in the traditional sense).

If we wanted to tighten that up later, it'd be a coordinated two-sided change: narrow this guard to is_wpcom_simple() only, and add a matching is_wpcom_simple() guard to wpcom_add_stats_to_site_menu() in jetpack-mu-wpcom so Atomic doesn't end up with two links. Filed as STATS-292 rather than blocking this PR on it.