Conversation
`Product::does_site_have_feature()` always fetched `/sites/%d/features` to answer a question WordPress.com can already answer in-process there: wpcomsh exposes `wpcom_site_has_feature()` on Atomic, gating from the same data the endpoint is built from. Hijack to it when it is available, the way `Current_Plan::supports()` already does, guarded by `wpcom_feature_exists()` so a slug WordPress.com does not gate falls through to the feature list instead of being answered "no" by a registry that never had it. Every slug My Jetpack looks up — ai-assistant, antispam, backups, cloud-critical-css, scan, search, social-enhanced-publishing, stats-paid, videopress, republicize — is a WPCOM_Features map key, so all of them take the local path. Besides removing a blocking request per dashboard render, this makes the answer independent of WordPress.com being reachable: a failed fetch used to read as "no feature", which could offer an upsell to a site that owns the product. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
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! |
Code Coverage SummaryCoverage changed in 1 file.
|
|
closing this, I had originally started it to help with #52495, but then decided to take the PR in a direction that didn't require requesting site features |
Allows WoA sites to do feature checks without a remote call to WPCOM
Does this pull request change what data or activity we track or use?
No
Testing instructions