Premium Analytics: show the Ads tab on WordPress.com only while WordAds is on

[dognose24]

Fixes WOOA7S-2208

Proposed changes

The product call on the soft-launch thread: follow classic Stats, which shows the Ads tab only when the site is actually using WordAds.

On WordPress.com the Ads section is registered by jetpack-mu-wpcom when the plan includes the WordAds feature, so every Premium-and-up Simple or Atomic site gets an Ads tab, with empty earnings if ads were never turned on (jetpacklive.wordpress.com, for one). Classic gates on the sites API's options.wordads, wpcom's has_wordads(): WordAds actually enabled. Self-hosted sites already match classic, since the WordAds module registers the section only while it is active.

• The registrant now requires the plan feature and WordAds enabled, through wpcom_premium_analytics_wordads_is_enabled().
• Atomic: the WordAds module, Modules::is_active( 'wordads', false ). A site with the module off is not running ads, whatever its approval sticker says: Odyssey ends up reading the shadow site's stickers through jetpack/v4/site and shows the tab on such a site, so this is stricter than Odyssey there, on purpose. Not available_only: the module list is not loaded on every request that hydrates the registry.
• Simple: the same two stickers the sites API's has_wordads() reads there (trait.json-api-site-wpcom.php on wpcom): has_any_blog_stickers( array( 'wordads-approved', 'wordads-approved-misfits' ), $blog_id ). Behind function_exists(), falling back to no tab, as the package's other sticker checks do.
• The manage_options gate is unchanged.

Tests: Atomic with the module off registers nothing; Simple follows the stickers, and the registrant asks for exactly those two. Docs, the sections diagram, the Ads package README and docblock and the module registrant's comments now describe the gate as plan feature plus WordAds on.

Supersedes #52766. That PR was closed as addressed by #52635, but #52635 moved the registrant with its plan-only gate intact: wpcom_premium_analytics_site_has_wordads() still checks wpcom_site_has_feature( 'wordads' ) and nothing else, and the jetpack-ads package's own is_available is just manage_options. So once #52864 put Ads back in the customer preview, every Premium-and-up Simple or Atomic site shows the tab again, WordAds on or not; a Simple site still at "Apply to Join WordAds" gets it. GitHub would not reopen #52766 after the rebase, hence the new PR (context). This is the same change rebased on trunk after #52635 and #52864. The check now sits inside wpcom_premium_analytics_site_has_wordads(), which both the section and the widget-type registrants read, so the widget types follow the tab.

Related product discussion/links

• WOOA7S-2208, from the soft-launch thread in #premium-analytics (2026-09-24).
• The plan-feature gate dates from Premium Analytics: add an Ads dashboard section for WordAds #51422 and moved through Premium Analytics: move the built-in dashboard sections out of the section API file #52450 and Premium Analytics: let the WordAds owners register the Ads tab #52455 unchanged.
• Premium Analytics: move the Ads widgets to the jetpack-ads package #52635 moved this registrant into jetpack-mu-wpcom calling the jetpack-ads package; Premium Analytics: Put the Ads tab back in the customer preview #52864 put the Ads tab back in the preview.

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

No.

Testing instructions

• jp test php packages/jetpack-mu-wpcom passes.
• Atomic (wpcomsh build from this branch, plan with WordAds): with the WordAds module off, Stats v2 shows no Ads tab and ?section=ads falls back to Traffic; switch the module on and the tab appears.
• Simple (sandbox): bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/premium-analytics-ads-tab-wordads-enabled, then sandbox public-api.wordpress.com, not only the site: the tab list comes from the wpcom/v2/sites/<blog_id>/dashboards/jetpack-premium-analytics_dashboard/sections REST call, which is where this registrant runs. With only the site host sandboxed the change looks inert.
  • A Premium site without the wordads-approved sticker no longer shows the tab, and ?section=ads falls back to Traffic. wp blog-stickers get --blog_id=<id> tells you which a site is (wp eval is disabled on the sandbox).
  • Give it the sticker and the tab comes back with its three widgets: wp blog-stickers add --blog_id=<id> --sticker=wordads-approved --who=<your login> --note="Testing jetpack#52903". Remove it afterwards with wp blog-stickers remove, same arguments: the sandbox writes to the production database.
  • A free site still shows no tab.

🤖 Generated with Claude Code

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the update/premium-analytics-ads-tab-wordads-enabled branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/premium-analytics-ads-tab-wordads-enabled

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/premium-analytics-ads-tab-wordads-enabled

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[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 a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ 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 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: October 6, 2026

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

---

Wpcomsh plugin:

• Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

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

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/jetpack-mu-wpcom/src/features/premium-analytics/wordads-section.php	10/16 (62.50%)	7.95%	1 ❤️‍🩹

Full summary · PHP report · JS report

[Nikschavan]

Thank you, the changes look good.

The docs still describe the old gate. dashboard-sections.md#L200 says jetpack-mu-wpcom registers Ads "when the plan includes WordAds", and line 202 gives the module being routinely off on Atomic as the reason to ignore it, which this PR reverses. The same "by plan feature" wording is in dashboard-widgets.md#L234, packages/ads/README.md#L5 and the two comments in class-wordads-premium-analytics.php. Updating them here would keep the docs in step with the new gate.

[Nikschavan]

Reading the module here is the right rule, but the reason in this comment does not hold: Odyssey only seeds options.wordads from the module in Odyssey_Config_Data, and the jetpack/v4/site request on load replaces it with the shadow site's has_wordads(), which reads the approval stickers. On a site with the sticker and the module off, Odyssey shows the Ads tab and this PR hides it. Hiding it seems correct to me, since a site with the module off is not running ads, so it may be worth wording the comment (and the description) as that rule rather than as matching Odyssey.

[dognose24]

Good catch, thank you. Reworded in 97cdd38: the comment now states the rule, a site with the WordAds module off is not running ads whatever its approval sticker says, rather than claiming to match Odyssey. The PR description says the same.

[dognose24]

Tested on Simple (sandbox, with public-api.wordpress.com sandboxed as well): a Premium site without the wordads-approved sticker no longer shows the Ads tab and ?section=ads falls back to Traffic; adding the sticker with wp blog-stickers add brings the tab and its three widgets back, and removing it hides them again.

Atomic still runs Premium Analytics from Jetpack 16.2, whose preview exposes Traffic only, so the Ads tab can't appear there until 16.3 regardless of this gate.

[dognose24]

Thanks for the review. 97cdd38 updates every place that still described the plan-only gate: dashboard-sections.md (the WordPress.com paragraph and the diagram alt text), dashboard-widgets.md, the sections diagram itself, packages/ads/README.md and the Analytics_Dashboard docblock, and both comments in class-wordads-premium-analytics.php. The Atomic comment in wordads-section.php now states the rule instead of pointing at Odyssey, per the inline thread. Docs-only projects got empty changelog entries.