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
Update/implement connect to jetpack #38674
Conversation
c703a7b
to
41f25dc
Compare
Hi @jorgeatorres, @chihsuan, @adrianduffell, Apart from reviewing the code changes, please make sure to review the testing instructions as well. You can follow this guide to find out what good testing instructions should look like: |
Test Results SummaryCommit SHA: cb64a45
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
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.
@moon0326 Nice work getting started and thanks for providing an early draft! 👍
I've left some thoughts about the endpoint
$redirect_url = apply_filters( 'woocommerce_admin_onboarding_jetpack_connect_redirect_url', esc_url_raw( admin_url( 'admin.php?page=wc-admin' ) ) ); | ||
$calypso_env = defined( 'WOOCOMMERCE_CALYPSO_ENVIRONMENT' ) && in_array( WOOCOMMERCE_CALYPSO_ENVIRONMENT, [ 'development', 'wpcalypso', 'horizon', 'stage' ], true ) ? WOOCOMMERCE_CALYPSO_ENVIRONMENT : 'production'; | ||
|
||
return [ | ||
'url' => add_query_arg( | ||
[ | ||
'from' => apply_filters( 'woocommerce_admin_onboarding_jetpack_connect_from_arg', 'woocommerce-onboarding' ), | ||
'calypso_env' => $calypso_env, | ||
], | ||
$manager->get_authorization_url( null, $redirect_url ) | ||
), | ||
]; |
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.
Can the redirect_url
and from
values be passed to the endpoint as parameters?
Looking into the future a bit, I think the connection screen will need to render differently (progress bar, copy, images) depending on what the user was doing:
- Selecting Jetpack in Core Profiler
- Setting up mobile app
- Using an AI feature
- Setting up shipping / mobile task
I'm thinking that each of those features above would perform the REST API request with granular redirect_url
and from
values relating to the feature. If we did that, the connection screen could then be customized for each feature as needed, and have redirection back to where the user started from.
I think maybe you had the same idea with the filters but I'm not sure it can support this level of granularity?
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 agree, I think it might be better as URL parameters. Using filters requires PHP for it to work, and I think it risks "leaks" (i.e.: A plugin unintentionally registers the filter in a global code), whereas URL param requires more deliberate use.
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.
Thank you both! Updated in a5f3581
// Register the site to wp.com. | ||
if ( ! $manager->is_connected() ) { | ||
|
||
$result = $manager->try_registration(); |
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 like try_registration()
has a $tos_agree
param. I think we'll need to pass that state through here - with the plugin guidelines we would want to avoid Jetpack servers until users have knowingly agreed to it.
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.
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.
@moon0326 ,what about in contexts outside of the onboarding wizard?
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 think it could be solved with a tos_agree
endpoint parameter as well. I think we need to consider that various parties will use this endpoint and there should be protection against accidental requests to Jetpack servers
Oops, didn't mean to approve a draft 😅
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.
Jetpack connection tests well!
Both Jetpack Connection Rest Auth and Config are loaded on every page. It seems like this is required for Jetpack to work, but I would like to find a way to load them conditionally, as we only need Jetpack when the user selects Jetpack during the core profiler.
I agree, we should find a way to selectively load the classes. A naive way to do it might be via detecting relevant URLs?
I'm setting slug as woocommerce in the config, but I'm not sure how/where this value is used exactly. I could not find the value on WPCOM.
I found it stored in jetpack_connection_active_plugins
. This is then used in multiple places, one notable is that it's synced with WPCOM (1, 2). AFAIK it's not a requirement for our use case, but I imagine a possibility is we could have some WC related data periodically synced to WPCOM.
However, note that we already have WooCommerce-related data sync built-in into Jetpack plugin - which powers mobile app AFAIK. I don't think we have any need to utilize this feature yet.
target: 'sendToJetpackAuthPage', | ||
cond: ( _context ) => | ||
_context.pluginsSelected.find( | ||
( plugin ) => plugin === 'jetpack' |
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 wonder if this is sufficient, I remember being redirected to Jetpack auth when Jetpack is installed but not connected and I selected WooCommerce Tax extension in OBW.
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.
However I'm not sure if that logic came from WC Core or Tax plugin
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.
Good suggestion. I'll check WooCommerce Tax and Shipping.
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 current OBW only considers Jetpack. I still think it's a good idea to redirect to Jetpack auth when WooCommerce Tax or Shipping is selected. Let's implement that in a separate PR, 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.
Sounds good!
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, I just tested in a JN with the current WooCommerce. It seems like if Jetpack is activated but the site is not connected, it will still go to auth screen even though I didn't select any extension to install.
Do we need to adopt the same logic?
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 far as I understand, we should only redirect to Jetpack auth when Jetpack is selected. Let's check with @verofasulo ✋
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've clarified this in the design call, we're fine with the current logic of only going with the auth flow when Jetpack is selected 👍
Thank you for looking into it 🙏 |
Hey @woocommerce/proton ✋ Ghidorah is working on adding Jetpack Connection for the new core profiler project. We've made the following changes.
Could you please review these changes when you get a chance please 🙏 ? |
Nice work, @moon0326! 👍 Should we add more instructions on how to go to the core profiler flow to help other teams know how to test this? 🙂 I think we can copy the instructions from previous PR such as #38620. I've also added a snippet command to TextExpander for core profiler |
Thanks! Updated! |
…o communicate back to the connected site
Co-authored-by: Ilyas Foo <foo.ilyas@gmail.com>
Co-authored-by: Ilyas Foo <foo.ilyas@gmail.com>
* Extracted out isJetpackConnected cond to a guard * Added meta data for isJetpackConnected to prevent unwanted spinner
dc3029d
to
7bb26f7
Compare
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 @moon0326 thanks for the great work on this! 🚀
Submission Review Guidelines:
Changes proposed in this Pull Request:
This is still WIP, but I'm opening it now to receive feedback and unblock other Jetpack login page PRs.
Jetpack Authorization is functioning as expected, but I'm not 100% comfortable.
slug
aswoocommerce
in the config, but I'm not sure how/where this value is used exactly. I could not find the value on WPCOM.I'll look into these two next week as we learn more about how Jetpack works.
You can find more about Jetpack Connection setup from the following repos:
This was part of https://github.com/woocommerce/team-ghidorah/issues/211, but never implemented in the original PR.
How to test the changes in this Pull Request:
In order to generate Jetpack auth URL, your local env must be publicly accessible. Either use Jurassic Tube or Ngrok to expose your local env.
If you want to change
from
value for testing purposes, change the value from this line