-
Notifications
You must be signed in to change notification settings - Fork 797
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
Jetpack core api: Refactor and reuse trait for proxying requests to WPCOM #40245
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. 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. |
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.
Nice work, and the extent of the tests is fantastic!
I tested functionality on all three platforms and from what I could see the two blocks worked as I'd expect.
I also left some review comments, let me know what you think (none are blockers). I reviewed from the perspective of testing and code reviewing, rather than from the point of view of understanding the best endpoint approach (following the linked Slack thread).
...ugins/jetpack/_inc/lib/core-api/wpcom-endpoints/trait-wpcom-rest-api-proxy-request-trait.php
Outdated
Show resolved
Hide resolved
...ugins/jetpack/_inc/lib/core-api/wpcom-endpoints/trait-wpcom-rest-api-proxy-request-trait.php
Outdated
Show resolved
Hide resolved
public function test_list_products_no_auth() { | ||
wp_set_current_user( 0 ); | ||
|
||
$request = new WP_REST_Request( Requests::GET, '/wpcom/v2/memberships/products' ); |
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.
Could it be worth defining some of the endpoint URLs as class constants to prevent possible issues if anything changes? such as const PRODUCTS_ENDPOINT = '/wpcom/v2/memberships/products';
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.
TBH I'd prefer the test to fail on purpose if someone redefines the endpoint path :)
public function test_list_products_with_insufficient_permissions() { | ||
wp_set_current_user( static::$author_id ); | ||
|
||
$request = new WP_REST_Request( Requests::GET, '/wpcom/v2/memberships/products' ); |
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.
As most of the tests make requests, I wonder if it might be worth extracting the request logic into a helper function? A similar example is here:
jetpack/projects/plugins/jetpack/tests/php/_inc/lib/test_class.rest-api-endpoints.php
Line 106 in 18cc457
protected function create_and_get_request( $route = '', $json_params = array(), $method = 'GET', $params = array() ) { |
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'm personally ok with repeating the new WP_REST_Request
part and setting headers and body independently in each test as per out needs.
I find methods like this a bit restricting in eg adding additional headers or interacting with the WP_REST_Request
object as needed, and they tend to grow over time in terms of params and custom logic.
That said, if we'd like to use a helper method like this perhaps we could do that in the future as part of refactoring the tests to use a common trait?
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.
Yes, perhaps if there is a need to come back and generally refactor or add more tests, it might make sense then too.
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 is nice, thanks for working on this! And the added tests will help too.
I only have a minor question, not a blocker for me.
...ugins/jetpack/_inc/lib/core-api/wpcom-endpoints/trait-wpcom-rest-api-proxy-request-trait.php
Show resolved
Hide resolved
…it-wpcom-rest-api-proxy-request-trait.php Co-authored-by: Karen Attfield <[email protected]>
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.
LGTM! 👍
This PR refactors the existing
WPCOM_REST_API_Proxy_Request_Trait
so that it can be used by any shared endpoint (between self-hosted and Simple sites) that needs to forward the request to WPCOM when it runs on the Jetpack end.It also refactors two existing endpoints to use the trait and introduces unit tests for both:
WP_Test_WPCOM_REST_API_V3_Endpoint_Blogging_Prompts
WPCOM_REST_API_V2_Endpoint_Memberships
Proposed changes:
WPCOM_REST_API_Proxy_Request_Trait
:proxy_request_to_wpcom
to allow falling back to using the Site-level Connection if the current user is not connectedproxy_request_to_wpcom_as_user
for proxying requests to WPCOM on behalf of the current userproxy_request_to_wpcom_as_blog
for proxying requests to WPCOM using the Site-level ConnectionWP_Test_WPCOM_REST_API_V3_Endpoint_Blogging_Prompts
:WPCOM_REST_API_Proxy_Request_Trait
traitWPCOM_REST_API_V2_Endpoint_Memberships
:WPCOM_REST_API_Proxy_Request_Trait
traitOther information:
Jetpack product discussion
p1730895681631659-slack-C05PV073SG3
Does this pull request change what data or activity we track or use?
No
Testing instructions:
bin/jetpack-downloader test jetpack update/forward-wpcom-request-trait