-
Notifications
You must be signed in to change notification settings - Fork 799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix site specific features passed to front-end for simple sites #39817
base: trunk
Are you sure you want to change the base?
Conversation
* | ||
* @return array | ||
*/ | ||
public static function get_simple_site_specific_features() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is copied here, with an added simple site check
jetpack/projects/plugins/jetpack/class.jetpack-gutenberg.php
Lines 1159 to 1174 in 347b86a
private static function get_site_specific_features() { | |
$current_blog_id = get_current_blog_id(); | |
if ( isset( self::$site_specific_features[ $current_blog_id ] ) ) { | |
return self::$site_specific_features[ $current_blog_id ]; | |
} | |
if ( ! class_exists( 'Store_Product_List' ) ) { | |
require WP_CONTENT_DIR . '/admin-plugins/wpcom-billing/store-product-list.php'; | |
} | |
$site_specific_features = Store_Product_List::get_site_specific_features_data( $current_blog_id ); | |
self::$site_specific_features[ $current_blog_id ] = $site_specific_features; | |
return $site_specific_features; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Automattic/jetpack-crew @Automattic/jetpack-garage this is where I need your feedback. I want to know whether this is OK to do here.
Plans::get_plans()
already does something similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks OK to me, since we're making sure first that this is a Simple site environment. And I think copying the method is a valid approach to make sure we're leaving old methods in place.
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 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Follow this PR Review Process:
Still unsure? Reach out in #jetpack-developers for guidance! |
Prepares the ground for https://github.com/Automattic/jetpack-reach/issues/511
Now that we have started consolidating our initial state via our
script-data
package, there is something we still need to fix. We want to be able to check for specific features in our front-end code. Right now, that logic is used in a weird way - sometimes viagetJetpackExtensionAvailability
and sometimes the feature checks are passed from the backend as boolean flags and there are too many of them and often repeated at multiple places. On the backend,Current_Plan:supports()
works fine for both Jetpack and Simple sites to check if a feature is available for a site or not butCurrent_Plan::get()
doesn't work as expected. It returns an empty set of features for Simple sites.So, in order to have a single source of truth to check features on client-side, we need to pass all the available features down to the client-side code via
script-data
package.This PR extracts the logic used here to
Current_Plan::get_simple_site_specific_features()
and updates the script data to override features for simple sites using that function.This allows us to have a utility function like
siteHasFeature
on client-side work reliably, both for Jetpack and Simple sites.Why do we need this?
We at Jetpack Reach are migrating all of our scattered initial to the consolidated initial state (script data) and thus we also want to move away from passing the boolean flags for features and the flags like
hasPaidPlan
,hasPaidFeatures
etc. to avoid unintentional bugs when features are moved between plans (free/paid) and thus we want to explicitly check for exact feature availability, which is the recommended way. So, we needsiteHasFeature
utility.Proposed changes:
get_simple_site_specific_features
method toCurrent_Plan
siteHasFeature
functionOther information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions:
JetpackScriptData.site.plan.features