-
Notifications
You must be signed in to change notification settings - Fork 801
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
Connection: add partner codes to connection URLs & deprecate Partner package #33832
Conversation
This was previously only done in the Jetpack plugin, in 2 ways: - The Partner package is initialized on plugins_loaded in the main Jetpack class. - In Jetpack's `build_authorize_url` method we have a `jetpack_build_authorize_url` filter that is leveraged by the Partner package. Standalone plugins, on the other hand, do not use `Jetpack::build_authorize_url()`. This method is obviously only available in the Jetpack plugin, and so standalone plugins do not have that `jetpack_build_authorize_url` filter. We fix this discrepancy in this commit: - We now initialize the Partner package in the connection package. - We add the `jetpack_build_authorize_url` filter to the connection package's `get_authorization_url` method, so the partner codes can be added to all URLs. **Note**: this does not add the Partner package as a new dependency for the Connection package, since the Partner package already declares the connection package as a dependency.
It is no longer needed now that the package is set up as part of the connection package
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. Once your PR is ready for review, check one last time that all required checks appearing at the bottom of this PR are passing or skipped. 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. Backup plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Boost plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Search plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Social plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Starter Plugin plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Protect plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Videopress plugin:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Migration plugin:
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.
I followed the instructions for testing both the Jetpack plugin and Boost and could see the query parameters. I appreciate how the code changes were documented 👍
The test failure outlines an interesting problem. It fails for the Inspect plugin, most likely because it doesn't include the My Jetpack package, so the Partner package is never required. I'm not quite sure how to fix that.
@anomiex Could I have your opinion about this? |
Offhand I don't know how Composer would handle it, but I know our CI will complain about a circular dependency. We'll want to avoid that.
Yeah, that's cheating. We don't want that to be the long-term solution either, it'll just bite someone else who uses the Connection package in the future. I see a few options that could work:
|
That's something I was thinking about, but I wasn't sure everyone was going to be okay with that. 👍 |
…er-standalone-sites
Hi @jeherve. |
…er-standalone-sites
…er-standalone-sites
Hi @jeherve. |
…er-standalone-sites
Proposed changes:
This PR changes the way the Partner codes were added when connecting a site to a WordPress.com account, so this can work with standalone plugins.
This was previously only done in the Jetpack plugin, in 2 ways:
build_authorize_url
method we have ajetpack_build_authorize_url
filter that is leveraged by the Partner package.Standalone plugins, on the other hand, do not use
Jetpack::build_authorize_url()
. This method is obviously only available in the Jetpack plugin, and so standalone plugins do not have thatjetpack_build_authorize_url
filter.We fix this discrepancy in this PR:
jetpack_build_authorize_url
filter to the connection package'sget_authorization_url
method, so the partner codes can be added to all URLs.Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions:
There may be an easier way to test this, but here is how I went about it.
wp option update jetpack_partner_subsidiary_id jeremy
wp option update jetpack_affiliate_code 123456
jetpack.wordpress.com
requestsaff
and asubsidiaryId
argument, using the values defined above.