Survicate: skip internal P2 sites and add is_big_sky_site visitor trait

[paulopmt1]

Fixes DOTOBRD-431

Proposed changes

We want to skip Survicate on three surfaces: Internal P2s, Big Sky, and WPCOM internal-tools admin screens.

• Internal P2s — hard-block. Survicate previously loaded on every wp-admin page for logged-in English users, including internal Automattic P2s (Atomic powers them too). should_load() now bails early when \Automattic\Jetpack\Status\Host::is_p2_site() returns true, which covers both pub/p2-* stylesheets and the \WPForTeams\is_wpforteams_site() signal. No new local helper — we call the canonical Status\Host method directly.
• Network / user admin — hard-block. is_admin() is true for /wp-admin/network/* and /wp-admin/user/* too, so the existing guard was still enqueuing Survicate on wpcom's network admin (e.g. wordpress.com/wp-admin/network/admin.php) — a wpcom internal-tools surface that the P2 check doesn't cover because the main wpcom blog isn't a P2. should_load() now also short-circuits on is_network_admin() || is_user_admin().
• Big Sky — is_big_sky_site visitor trait. The CES survey "how easy was it to edit your site template today" doesn't apply to AI-driven Big Sky flows. Emit a new is_big_sky_site visitor trait (string "true"/"false") — true when either the big-sky-enabled or big-sky-free-trial blog sticker is set. The actual exclusion is configured in Survicate's targeting UI, so future Big Sky-targeted surveys are still possible without a code change.

Related product discussion/links

• Slack thread: p1777559033485849-slack-C04H4NY6STW
• Linear: DOTOBRD-431

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

No new data is collected. A new visitor trait (is_big_sky_site) is sent to Survicate alongside the traits we already pass (email, site_id, site_type, editor_context). Its only purpose is to let Survicate's targeting UI exclude Big Sky users.

Survicate dashboard follow-up (post-deploy)

The trait alone doesn't filter anything — the targeting rule lives in Survicate's UI. After this lands and rolls out:

1. Open the CES survey "how easy was it to edit your site template today" → Targeting → add condition: exclude visitors where is_big_sky_site equals "true".
2. Spot-check other active surveys for any with explicit site_type targeting that would reach internal P2 sites — the P2 hard-block already handles this server-side, but worth confirming nothing else is misconfigured.

Testing instructions

Unit tests

cd projects/packages/jetpack-mu-wpcom
composer phpunit -- tests/php/features/survicate/Survicate_Test.php

Should pass 27 tests, including 7 new ones:

• test_should_load_returns_false_on_p2_site_via_stylesheet
• test_should_load_returns_false_on_p2_site_via_wpforteams
• test_should_load_returns_false_on_network_admin
• test_should_load_returns_false_on_user_admin
• test_get_visitor_traits_returns_is_big_sky_site_false_by_default
• test_get_visitor_traits_returns_is_big_sky_site_true_for_big_sky_enabled_sticker
• test_get_visitor_traits_returns_is_big_sky_site_true_for_big_sky_free_trial_sticker

Manual verification (Jurassic Ninja)

P2 hard-block:

1. Spin up a JN site, switch to a P2 theme (e.g. pub/p2-2020), log in as an English user.
2. Open any wp-admin page and check the Network panel.
3. Expected: no request to survey.survicate.com. The Survicate inline script is not enqueued.

Network / user admin hard-block (wpcom sandbox):

1. As an Automattician, open https://wordpress.com/wp-admin/network/admin.php (or any /wp-admin/user/* URL).
2. Check the Network panel for survey.survicate.com requests and the page source for the inline Survicate bootstrap.
3. Expected: nothing enqueued. Regular /wp-admin/* on a user site should still enqueue as before.

Big Sky trait:

1. On a regular (non-P2) wp-admin page on a normal site:
   • DevTools Console → wait for SurvicateReady → inspect the _sva calls or use window._sva.getVisitorTraits?.().
   • Expected: traits payload includes is_big_sky_site: "false".
2. Simulate a Big Sky site by adding the big-sky-enabled blog sticker (or filtering wpcom_has_blog_sticker for the test environment).
   • Expected: traits payload includes is_big_sky_site: "true".
3. In the Survicate UI on a test workspace, configure a survey to exclude is_big_sky_site = "true". Reload the page.
   • Expected: the survey does not display when the trait is true; displays when false.

Regression check

Confirm Survicate still loads as before on:

• A normal English-locale wp-admin page on a non-P2, non-Big-Sky site → script enqueues, traits include editor_context, site_type, etc.
• All existing should_load() short-circuits (logged out, non-admin, non-English locale) still return false.

[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 (WordPress.com Site Helper), and enable the add/survicate-big-sky-p2-exclusions branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/survicate-big-sky-p2-exclusions

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!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/jetpack-mu-wpcom/src/features/survicate/class-survicate.php	56/58 (96.55%)	-1.36%	1 ❤️‍🩹

Full summary · PHP report