Skip to content
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

Issue / 10169 Plugin Detection Logic #10209

Open
wants to merge 14 commits into
base: develop
Choose a base branch
from

Conversation

10upsimon
Copy link
Collaborator

@10upsimon 10upsimon commented Feb 12, 2025

Summary

Addresses issue:

Relevant technical choices

PR Author Checklist

  • My code is tested and passes existing unit tests.
  • My code has an appropriate set of unit tests which all pass.
  • My code is backward-compatible with WordPress 5.2 and PHP 7.4.
  • My code follows the WordPress coding standards.
  • My code has proper inline documentation.
  • I have added a QA Brief on the issue linked above.
  • I have signed the Contributor License Agreement (see https://cla.developers.google.com/).

Do not alter or remove anything below. The following sections will be managed by moderators only.

Code Reviewer Checklist

  • Run the code.
  • Ensure the acceptance criteria are satisfied.
  • Reassess the implementation with the IB.
  • Ensure no unrelated changes are included.
  • Ensure CI checks pass.
  • Check Storybook where applicable.
  • Ensure there is a QA Brief.
  • Ensure there are no unexpected significant changes to file sizes.

Merge Reviewer Checklist

  • Ensure the PR has the correct target branch.
  • Double-check that the PR is okay to be merged.
  • Ensure the corresponding issue has a ZenHub release assigned.
  • Add a changelog message to the issue.

Copy link

github-actions bot commented Feb 12, 2025

Build files for b3f3ae2 are ready:

@10upsimon
Copy link
Collaborator Author

10upsimon commented Feb 12, 2025

Note to reviewer

Please see this comment against the issue as to why the implementation is slightly different to the IB, thank you.

Copy link
Collaborator

@zutigrm zutigrm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @10upsimon looks good overall, I left you a few comments

@@ -760,6 +761,54 @@ private function get_inline_base_data() {
'isMultisite' => is_multisite(),
);

if ( Feature_Flags::enabled( 'adsPax' ) ) {
$inline_data['plugins'] = array(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure we need this additional nesting, it only complicates already nested structure 🤔 . It does related to plugins, although this goes into the core site namespace, and plugins are technically within the site scope

@@ -18,6 +18,7 @@
use Google\Site_Kit\Core\Util\URL;
use WP_Dependencies;
use WP_Post_Type;
use Google\Site_Kit\Core\Util\Plugin_Status;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's group this import together with other imports from Site_Kit namespace

Comment on lines +777 to +798
// Get the status of the WooCommerce plugin.
$woocommerce_plugin_status = Plugin_Status::get_plugin_status( 'woocommerce/woocommerce.php', 'https://woocommerce.com/' );

// Get the status of the Google for WooCommerce plugin.
$google_for_woocommerce_plugin_status = Plugin_Status::get_plugin_status( 'google-listings-and-ads/google-listings-and-ads.php', 'https://wordpress.org/plugins/google-listings-and-ads' );

switch ( $woocommerce_plugin_status ) {
case Plugin_Status::PLUGIN_STATUS_ACTIVE:
$inline_data['plugins']['woocommerce']['installed'] = true;
$inline_data['plugins']['woocommerce']['active'] = true;
break;
case Plugin_Status::PLUGIN_STATUS_INSTALLED:
$inline_data['plugins']['woocommerce']['installed'] = true;
$inline_data['plugins']['woocommerce']['active'] = false;
break;
}

switch ( $google_for_woocommerce_plugin_status ) {
case Plugin_Status::PLUGIN_STATUS_ACTIVE:
$inline_data['plugins']['google-listings-and-ads']['installed'] = true;
$inline_data['plugins']['google-listings-and-ads']['active'] = true;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we can extract woo and GfW logic of computing the inline data, and return of the inline data itself into a separate module, to keep both of the methods more compact

} else {
foreach ( $plugins as $plugin_file => $installed_plugin ) {
if ( $installed_plugin['PluginURI'] === $plugin_uri ) {
$plugin = $plugin_file;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure it is safe to remove this re-assignment of $plugin? We do define it at the top of the function based on the known path, which should be enough, but there might be instance it was not enough that we had to match it by URI and re-assign it, might be worthwhile confirming this @nfmohit who did this initial implementation

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but there might be instance it was not enough that we had to match it by URI and re-assign it

@zutigrm we do this further second matching on the Plugin_Status class now, so it should be okay? cc @nfmohit

@@ -713,7 +705,7 @@ protected function inline_module_data( $modules_data ) {
$inline_data['existingClientID'] = $existing_client_id;
}

$is_woocommerce_active = $this->woocommerce->is_active();
$is_woocommerce_active = Plugin_Status::PLUGIN_STATUS_ACTIVE === Plugin_Status::get_plugin_status( 'woocommerce/woocommerce.php', 'https://woocommerce.com/' );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use this check in more then one place, it will be more efficient to wrap it within a separate method, like is_woocommerce_active that will handle this, and we can also store the result within the class property to avoid re-fetching the plugins and re-doing the same loop. We could call this method during the constructor or register method for example

Comment on lines +81 to +94
protected function enable_feature( $feature ) {
$enable_callback = function ( $enabled, $feature_name ) use ( $feature ) {
if ( $feature_name === $feature ) {
return true;
}
return $enabled;
};

add_filter( 'googlesitekit_is_feature_enabled', $enable_callback, 10, 2 );

return function () use ( $enable_callback ) {
remove_filter( 'googlesitekit_is_feature_enabled', $enable_callback, 10 );
};
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already defined in the main TestCase class

protected function enable_feature( $feature ) {
$enable_callback = function ( $enabled, $feature_name ) use ( $feature ) {
if ( $feature_name === $feature ) {
return true;
}
return $enabled;
};
add_filter( 'googlesitekit_is_feature_enabled', $enable_callback, 10, 2 );
return function () use ( $enable_callback ) {
remove_filter( 'googlesitekit_is_feature_enabled', $enable_callback, 10 );
};
}
which this test class extends, so this can be removed as there is no reason to override it

'installed' => false,
'active' => false,
),
'google-listings-and-ads' => array(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, one more thing, I know we planned to use this slug in the IB, but let's rename it to googleForWooCommerce, to be more clear what plugin is this about since that's how it is called now, and to adhere to general approach of not having kebab-case properties in the inline data, or data stores in general (with modules being exception since we have to adhere to the module slug everywhere)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants