-
Notifications
You must be signed in to change notification settings - Fork 798
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 connection package: How to handle disconnecting from Jetpack? #13843
Comments
That's my vote. We can add some type of language "Your site is still using X, Y, Z. To fully disassociate with WordPress.com/Jetpack/etc, please remove all of those plugins". Otherwise, we depend on other plugins to ensure they are accurately representing what is happening -- what if one doesn't implement the UI and just tries to disconnect? |
I didn't think deactivating (and re-activating) Jetpack left the user disconnected. Does it? Let's be super careful semantically here to always say disconnect when we mean disconnect. |
I don't know about Jetpack, but I didn't mention deactivating Jetpack at all. I did talk about the possibility of plugins X, Y, or Z deactivating, and that would disconnect the Jetpack connection. For example, if WooCommerce Shipping uses the Jetpack connection package, the user doesn't have any other plugins installed, and the user deactivates WooCommerce Shipping, what should happen there? Should the connection be fully destroyed? Or should the tokens be preserved in the database so then the plugin is re-activated, the connection can resume working normally? I guess we'll want to have the same behaviour as Jetpack proper.
I've edited the description to only use "disconnection" all around. What happens when the plugin is disabled/uninstalled is only tangentially related to this issue. |
My take is it should work the same way as Jetpack does today - that if I were to re-activate, it wouldn't require re-connection. |
Disconnection -- Specifically the technical piece where the Jetpack<->WP.com relationship is severed including invalidation of the shared tokens that secure communication. This destroys both the master connection and any secondary connected users. Deactivation -- The typical WordPress meaning of deactivating a plugin. In Jetpack, there is a deactivation hook that fires the disconnection functionality link. This would need to change as part of this work so we would only disconnect if we're the last plugin standing. Deletion -- The typical WordPress meaning. When a deactivated plugin is deleted via wp-admin. Fires What I'm thinking: Every consumer somehow adds a Something similar could be added in the (None of this has been prototyped, so I reserve the right to be wrong about the pseudocode above :) ). |
TIL. I was under the misapprehension that deactivation of Jetpack didn't cause a disconnect |
Love this idea. Extra points if the Also, with this approach (a plugin disconnecting only disconnects said plugin), the jetpack connection package should keep a map of |
Seems like a good first step to get things going.
Was thinking further down the road, (sorry can't help it) if this gains traction and wider use, adding a connections page to wp-admin settings would be handy. A place where the master user could be transferred, and connections could be managed etc. |
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
Adding this for visibility and discussion in the open. The Jetpack Connection Task Force kickoff meeting has prompted some discussion about this.
In a future where a third-party plugin is connected to wp.com using the Jetpack connection package, how do we handle the user disconnecting said connection?
The text was updated successfully, but these errors were encountered: