Feature Flags (a8c): show the screen on every proxied request, verify before saving

[enejb]

Fixes #

Proposed changes

Tools → Feature Flags (a8c), added in #51324, often doesn't show up for Automatticians on Atomic sites, even when the "PROXIED V2" banner and Debug Bar do. Those two only check AT_PROXIED_REQUEST. The Feature Flags screen also needs wpcomsh's _wpcomsh_support_session_detected cookie with the value false. That cookie is often missing:

• It is SameSite=Strict, so a cross-site navigation into wp-admin (from Calypso, Slack, a P2…) doesn't send it. The menu entry is missing on that first page load.
• It is only set on a fresh Jetpack SSO login, so a session that started some other way never has it.
• It expires on wpcom's schedule, which is separate from the WordPress login cookie.

This PR separates viewing the screen from saving on it:

• View: on Atomic, the menu entry and screen need AT_PROXIED_REQUEST + manage_options. That is the same condition as the PROXIED V2 banner. Simple is unchanged (is_automattician()).
• Save: handle_save() now uses a new current_user_can_save(). On Atomic it also needs a stored "not a support session" verdict, so a submission without one is refused on the server.
• When saving is blocked: the screen disables Save overrides and shows a notice explaining why:
  • No verdict stored: a Verify this session button runs wpcomsh's existing client-side detection (/_wpcomsh_detect_support_session). It then returns through /wp-login.php?redirect_to=<this screen>, which forwards a logged-in user straight back.
  • Support session: the screen is read-only and says saving is disabled during a support session.

Related product discussion/links

• Follow-up to Feature Flags: add an Automattician-only control screen on Simple and Atomic #51324 and Feature Flags: key the wpcom override cache by blog #52558.

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

No.

Testing instructions

You need a WoA dev site running this branch of jetpack-mu-wpcom (via wpcomsh), which you reach through the a8c proxy.

Menu visibility

1. With the proxy on, open the site's wp-admin from Calypso (a cross-site navigation).
2. In devtools → Application → Cookies, delete _wpcomsh_support_session_detected if it is there, then reload.
3. Tools → Feature Flags (a8c) shows up whenever the PROXIED V2 banner does. On trunk it is missing in this state.

Saving is blocked without a verdict

1. On the screen, with the cookie still missing, you see a "Saving is disabled until this browser is checked for a support session" notice, a Verify this session button, and a disabled Save overrides button.
2. Optional: re-enable the button in devtools and submit. You get "Your changes were not saved", and the stored states don't change.

Verification flow

1. Click Verify this session. You see the "Asking WordPress.com whether we are in a support session..." page for a few seconds.
2. You land back on Tools → Feature Flags (a8c) with no notice, and Save overrides is enabled.
3. _wpcomsh_support_session_detected is now set to false.
4. Force a flag on, save, and confirm you see "Overrides saved." Set it back to Default afterwards.

Support session

1. In a support session (or with the cookie set to true), the screen shows "Saving is disabled during a support session", no Verify button, and a disabled Save button.

Things to look out for

• Jetpack SSO taking over wp-login.php on the way back. If that happens, you should still end up on the screen with the cookie set, because SSO success sets it as well.
• On Simple, nothing changes: Automatticians can view and save exactly as before.

[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 fix/wpcom-feature-flags-menu-visibility branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack-mu-wpcom-plugin fix/wpcom-feature-flags-menu-visibility

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/wpcom-feature-flags/class-wpcom-feature-flags.php	255/268 (95.15%)	-0.03%	2 ❤️‍🩹

Full summary · PHP report · JS report