Image Studio: gate video clip generation by Image Studio enablement#48712
Conversation
Restrict image_studio_can_generate_video_clips() so video generation is only offered on plans/environments that surface Image Studio itself. is_image_studio_enabled() and wpcom_site_can_upload_videos() now act as hard gates ahead of the jetpack_image_studio_can_generate_video_clips filter, so a stray __return_true override cannot widen support past the underlying capability checks. Co-Authored-By: Claude Opus 4.7 (1M context) <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! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
|
Two pre-existing tests assumed the `jetpack_image_studio_can_generate_video_clips` filter could force-enable independently of `wpcom_site_can_upload_videos()`. Now that the wpcom helper is a hard gate ahead of the filter, those tests failed in WPCOMSH-style CI where the helper is defined and returns false. Mirror the existing process-isolation pattern (see test_can_generate_video_clips_true_when_wpcom_helper_true): run each test in a separate process and `eval`-stub `wpcom_site_can_upload_videos()` to return true so the filter's force-enable path is actually exercised. Also split the combined filter-override test into _true / _false variants so the _false case keeps running everywhere (it doesn't depend on the gate). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both `_filter_override_false` and `_inline_script_..._false_via_filter` could pass for the wrong reason in WPCOMSH-style envs where `wpcom_site_can_upload_videos()` returns false: the wpcom hard gate short-circuits to false before the filter is consulted, so the assertion succeeds without actually exercising the filter override. Process-isolate both tests and stub `wpcom_site_can_upload_videos()` to return true so both gates pass and the filter is the thing under test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
projects/plugins/jetpack/extensions/plugins/image-studio/image-studio.php:118
- The docblock sentence "Off-WPCOM ... we don't gate the entry point" is now a bit misleading since the function always hard-gates on
is_image_studio_enabled()even off-WPCOM. Consider rewording to clarify that only the video-upload capability gate is skipped off-WPCOM (while Image Studio enablement is still required).
* Requires that Image Studio itself is enabled on this site, so video clip
* generation is only offered on the same plans/environments that surface
* Image Studio. Also mirrors the WordPress.com server-side gate: defers to
* `wpcom_site_can_upload_videos()` when available so the client and server
* agree on capability. Off-WPCOM (self-hosted Jetpack, standalone VideoPress,
* dev environments) the helper isn't loaded; we don't gate the entry point in
* those contexts and let the server respond if generation is unsupported.
The previous wording ("we don't gate the entry point in those contexts")
became misleading once is_image_studio_enabled() became a hard gate that
runs everywhere. Reword to say Image Studio enablement is always required
and that only the `wpcom_site_can_upload_videos()` check is skipped
off-WPCOM.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…deo-clip-by-enablement
Fixes #N/A
Proposed changes
image_studio_can_generate_video_clips()now requiresis_image_studio_enabled()to be true; on sites where Image Studio itself isn't surfaced, video clip generation is also unavailable.is_image_studio_enabled()andwpcom_site_can_upload_videos()run as hard gates before thejetpack_image_studio_can_generate_video_clipsfilter. A stray__return_trueon the filter can no longer widen support past either capability check — it can still force-disable or set the off-WPCOM default.test_can_generate_video_clips_false_when_image_studio_disabled— function returns false when Image Studio is disabled.test_can_generate_video_clips_filter_cannot_override_disabled_image_studio—__return_truefilter cannot bypass the Image Studio gate.test_can_generate_video_clips_filter_cannot_override_no_video_upload—__return_truefilter cannot bypasswpcom_site_can_upload_videos()(process-isolated, stubs the helper).Related product discussion/links
Does this pull request change what data or activity we track or use?
No. No tracking changes; this is a capability-gate adjustment.
Testing instructions
window.imageStudioData.canGenerateVideoClipsistruein the post editor and the video clip generation entry point appears as before.canGenerateVideoClipsisfalseand the entry point is hidden.falseregardless of anyadd_filter( 'jetpack_image_studio_can_generate_video_clips', '__return_true' ).trueby default and the filter can still force-disable.jp docker phpunit jetpack -- --filter=Image_Studio_Test.