-
Notifications
You must be signed in to change notification settings - Fork 812
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
Move WordPress.com themes api into jetpack-mu-wpcom package #41770
base: update/php-8.1
Are you sure you want to change the base?
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 🤖 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. 🔴 Action required: Please add missing changelog entries for the following projects: Use the Jetpack CLI tool to generate changelog entries by running the following command: Follow this PR Review Process:
Still unsure? 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. Mu Wpcom 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.
6 files are newly checked for coverage. Only the first 5 are listed here.
Full summary · PHP report · JS report Add label
I don't care about code coverage for this PR
|
Haven't tested thoroughly, but this seems to work well on a WoA dev site (with both WordPress.com Site Helper and WordPress.com Features using this branch) — theme-install.php returns wpcom themes 👍🏻 When I deactivate "WordPress.com Features" though, the themes return to what's in core. I think that's expected with the dev process, but I just want to check that we're sure this code will load on both simple and atomic sites. Haven't tested on wpcom simple yet (though it should not do anything there, since these filters are never called). |
projects/packages/jetpack-mu-wpcom/src/features/wpcom-themes-api/themes.php
Outdated
Show resolved
Hide resolved
projects/packages/jetpack-mu-wpcom/src/features/wpcom-themes-api/themes.php
Outdated
Show resolved
Hide resolved
I made some changes here:
Testing: |
Actually, thinking about this some more, I wonder if we should leave some of this in wpcomsh, as it isn't relevant to Simple sites - particularly the stuff about symlinks etc. However the |
@@ -160,6 +160,11 @@ public static function load_wpcom_user_features() { | |||
require_once __DIR__ . '/features/wpcom-sidebar-notice/wpcom-sidebar-notice.php'; | |||
require_once __DIR__ . '/features/wpcom-themes/wpcom-themes.php'; | |||
|
|||
// We include WPCom Themes results and installation on WoA sites only and non-WP_CLI context. |
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.
Nit: I think it would be really helpful to future developers if we explained why we only enable in these contexts. Otherwise I think we can just remove the comment entirely.
projects/packages/jetpack-mu-wpcom/changelog/update-move-wpcom-themes-api
Show resolved
Hide resolved
projects/packages/jetpack-mu-wpcom/src/class-jetpack-mu-wpcom.php
Outdated
Show resolved
Hide resolved
Code Coverage SummaryCoverage changed in 2 files.
6 files are newly checked for coverage. Only the first 5 are listed here.
Add label
I don't care about code coverage for this PR
|
// Add results to the resulting array. | ||
return $wpcom_themes_service->filter_themes_api_result_recommended( $res ); | ||
} | ||
add_filter( 'themes_api_result', 'wpcomsh_popular_wpcom_themes_api_result', 0, 3 ); |
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.
We will want these to also run on WPcom in the untangling themes PR, right? Should we move them to run on WPcom now, or only in the untangling themes PR?
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.
I a bit torn on if we should rename these functions and move the filters over entirely or not. I think it's best to leave it as is. We don't need any of this on WPcom yet. It's probably best to enable it in untangling themes as that's when it's actually needed.
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.
Yeah I agree. If we keep this PR as just a code moving task, then we can consider changes in the future on a case by case basis. If we start changing things as well as moving them its gets harder to reason about.
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.
Actually, when I thought about the deploy process for this - because wpcomsh and jetpack-mu-wpcom are deployed at different times, I think it does make more sense to rename the functions now - that way we avoid errors when a function is redefined.
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.
I was worried about this too, but I think it's not an issue. I believe WoA sites run jetpack-mu-wpcom bundled as wpcomsh. They don't run the WPcom mu-plugin AND wpcomsh. So there should only be one version of anything running, even if deploy cycles are different. We should absolutely confirm to be sure though!
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.
Yeah I wasn't sure exactly how they fit together but @zinigor suggested it might be a problem and I thought better safe than sorry, since we want to rename anyway.
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.
I believe WoA sites run jetpack-mu-wpcom bundled as wpcomsh. They don't run the WPcom mu-plugin AND wpcomsh.
That's correct! I sometimes get confused with what environment gets affected with what. WoA and Atomic sites should be fine in this regard. The WordPress.com environment though will have these files removed added, but not used?
If that's so, then I'm sorry for causing additional anxiety about deploying this.
return $wpcom_themes_service->get_theme( $args->slug ) ?? $res; | ||
} | ||
add_filter( 'themes_api_result', 'wpcomsh_theme_information_wpcom_themes_api_result', 0, 3 ); | ||
|
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.
Should we move over this whole file? Or is what's left in this file separate enough that it's fine to leave in a separate location? As in, if someone needed to fix something related to the themes API, then they wouldn't need to work in both this file and jetpack-mu-wpcom/src/features/wpcom-themes/wpcomsh-themes.php
?
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.
I reviewed more thoroughly. I think this file can stay here and the separation is good. What's left in this file isn't about API calls. It's about symlinking wpcom themes for atomic sites, and doesn't run on api calls.
I think this PR code-wise is good to go. I'm going to take time this afternoon to test it on atomic. @scruffian - did you check any network requests in your testing? |
@@ -5,174 +5,6 @@ | |||
* @package wpcom-themes | |||
*/ | |||
|
|||
/** |
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.
Since this file isn't doing API things anymore, can you update the file comment ^?
Another idea (not blocking for this PR) would be to moved these symlink functions to
managed-themes.php — since there are other wpcom theme related functions there.
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.
Another idea (not blocking for this PR) would be to moved these symlink functions to
managed-themes.php
I think it's a good idea to move it. Those functions all fit together since they're about managing symlinked themes. I don't see a reason to have them in different files.
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.
The problem with moving it is that the conditions for loading wpcom-themes are different for the conditions for loading managed-themes. (wpcom-themes is not loaded in a CLI context). I'm not sure how deliberate this is.
if ( ( defined( 'IS_ATOMIC' ) && IS_ATOMIC ) && ( ! defined( 'WP_CLI' ) || ! WP_CLI ) ) { | ||
require_once __DIR__ . '/features/wpcom-themes/wpcomsh-themes.php'; | ||
} |
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.
What is the plan for removing this atomic gate? Can that be done here, or as part of a follow-up PR? Asking because I think it will help with a PR for the atomic transfer process (Automattic/wp-calypso#99761). And technically this shouldn't have any effect on simple sites yet anyway, since they don't call any install code.
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.
Ah, I see the PR description says "This matches existing Production but sets us up for future development", so I assume a future PR.
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.
Yeah I think its good to keep the PR purely for moving the code.
07b61ce
to
06513b1
Compare
I renamed the duplicated functions so that we can deploy without worrying about name conflicts. I also added |
d4eb451
to
d0a6f06
Compare
@scruffian - I split out the PHP 8.1 upgrade (#41928) and Phan (#41931) commits to separate PRs since they were necessary but unrelated to this work. Then I rebased this branch off of the PHP 8.1 upgrade branch and cherry-picked all the commits from this branch back. I have a local copy of the branch pre-rebasing if something is messed up. |
@scruffian - It seems like this is unnecessary too. Was the worry here if both the jetpack-mu-wpcom-plugin and wpcomsh get loaded? |
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.
Flagging the code that can probably be removed.
if ( class_exists( 'WPCom_Themes_Api' ) ) { | ||
return; | ||
} |
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.
Potentially unnecessary.
if ( class_exists( 'WPCom_Themes_Cache' ) ) { | ||
return; | ||
} |
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.
Potentially unnecessary.
if ( class_exists( 'WPCom_Themes_Mapper' ) ) { | ||
return; | ||
} |
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.
Potentially unnecessary.
if ( class_exists( 'WPCom_Themes_Merger' ) ) { | ||
return; | ||
} |
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.
Potentially unnecessary.
if ( class_exists( 'WPCom_Themes_Service' ) ) { | ||
return; | ||
} |
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.
Potentially unnecessary.
Yeah, i was thinking about what might happen if the the mu plugin is running at the same time as wpcomsh - since that plugin will be deployed before this one - I think we want to ensure that both changes can happen independently of each other since we can't guarantee the timings. I do also think it's generally good practice to check a class doesn't exist before you define it, just in case. |
Part of the Theme Untangling project. This PR should not impact any functionality.
Proposed changes:
We modify some WordPress.com themes API calls using hooks while in the wp-admin view on WordPress.com sites.
Currently we do this only for Atomic sites. This PR moves that modification code into a place where the modifications can also work for Simple sites.
Note: currently as of this PR the modifications will only be loaded on Atomic until such time as we want to include them on Simple. This matches existing Production but sets us up for future development.
In #41374 we are modifying these files, so it makes sense to move them first in one PR, so that we can see what modifications are being made in the other PR.
We need to think about how to release this, since the release cycle for wpcom's mu-jetpack-wcom plugin and wpcomsh differ.
Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions:
This PR should not change any functionality.
On a simple site
On an Atomic site