SEO: Add a per-site feature flag - #50899
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
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:
If you have questions about anything, reach out in #jetpack-developers for guidance! 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. Wpcomsh plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 2 files.
|
Ran the skill end to end against three PRs of deliberately different shape and fixed what each one broke: - #50899 (PHP package + admin surface): wrong SSH host fallback, `wp --version` smoke test that prints the help screen, `jnwp` documented as a shell function that cannot survive between tool calls, and wrong Beta Tester plugin slugs. - #50925 (JS-only package, front-end surface): step 2b had no path for asset-based PRs at all, and step 5a wrongly assumed every plan gate reads `jetpack_active_plan` (Search keeps its own option). - #50419 (standalone plugin, plugin-owned assets): shadowing does not apply to standalone targets, `get_installed_path()` does not apply to plugin-owned assets, and the bundle-grep recipe used `grep -c`, which counts lines and returns 1 for a minified bundle regardless. The substantive correction is step 2b. It framed autoloader shadowing as an edge case tied to stale branches and recommended a rebase. In fact branch and trunk normally share a base version, so the `-alpha<timestamp>` suffix is the tiebreak and production wins by default — observed losing by 5.3h on one PR and by 470s on another. A rebase does not fix that. The stale-branch flag and rebase advice now apply only to a genuinely lower base version. Also: act on PR `state` rather than just capturing it (merged PRs invert the shadowing analysis), treat an unfilled PR template as no testing instructions, make "no preconditions" an explicit valid outcome, and make step 6 prove the surface renders instead of assuming it — a run can now end "set up correctly but the feature needs infrastructure a local override cannot fake" rather than handing over a dead link. Readiness polling was wrong twice before landing: HTTP 200 arrives ~15s before configuration starts, and `jetpack-beta` is installed in JN's first phase. It now waits on `blogname`, the last command JN runs, verified across all 7 available site configs, with a documented fallback. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DYjcP1i48RfT2kA7XrkgND
Fixes #
Proposed changes
seo-admin-uiWordPress.com feature entry, following the existing Social UI v2 rollout pattern.rsm_jetpack_seofilter or the new site feature is active.This lets the SEO rollout be managed per site after the supporting code ships, while preserving the existing filter for development and self-hosted testing.
Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
Store_Product_Listchange deployed, add thejetpack-seo-admin-uiblog sticker to a test site and refresh its feature data.rsm_jetpack_seofilter, confirmseo-admin-uiis active and the Jetpack SEO menu/page loads.add_filter( 'rsm_jetpack_seo', '__return_true' );and confirm the existing filter still enables the menu/page.packages/seo,plugins/jetpack, andplugins/wpcomsh.