Wp-calypso: Hosting Configuration: Unable to view Hosting Config if Jetpack is disconnected

[samiff]

Steps to reproduce

1. With a WordPress.com Atomic site, disconnect the Jetpack connection.

What I expected

• To be able to access the site's Hosting Configuration (e.g. SFTP or phpMyAdmin credentials)

What happened instead

• If Jetpack is disconnected, the site won't appear in Calypso for the user, and thus they aren't able to view the Hosting Configuration.
• During migrations or security cleanup, access to SFTP for example is desirable regardless of Jetpack status on the site.

Context / Source

p9F6qB-5Af-p2#comment-31076

[davemart-in]

@gwwar mind weighing in on this one? From my limited perspective, there is no way to make this happen since a JP connection is required for a site to be accessible via Calypso.

[davemart-in]

Notes from backlog grooming

• If you're on Pressable you can access the hosting config even if JP connection is not made
• What is being suggested here is that we should stop relaying on JP for all hosting config settings
• If a customer can't access Atomic site because it's busted, they have no way to recover from it, we still have other ways to help them fix it. We have SSH connection. How can we solve this without having to involve HE's?
• Maybe we send an email giving them an SFTP password?

[gwwar]

The public-api relies on a Jetpack connection which means we may not be able to fix this within Calypso.

Flow-wise, this suggests we may need to send out a recovery flow via email (eg a link to generate new SFTP creds) or maybe we can help expose a recovery workflow for WordPress.com Atomic clients (similar to what Pressable is doing). I'd of course highly recommend deferring to @jmdodd's team if they had preferences on solutions here.

[jmdodd]

There may be a way to not allow Jetpack to be disconnected from a WordPress.com-on-Atomic site that would allow Calypso to remain available for these sites, or a way to repair the connection. Broken Jetpack connections are a long-standing pain point -- this is another data point for where that requirement breaks down in the UX.

The SFTP recovery flow via email may also help further the conversation around site ownership.

[davemart-in]

It would be helpful if we could figure out somehow how prevalent this is so that we can prioritize this.

[jordesign]

I did some rough napkin math analysing the 'jetpack_connection' HC tag in Looker. This is generally used for chats where work on the JP connection has been needed

7 Days:
42 interactions averaging 57.86m (~40 hours total)

30 Days:
393 interactions averaging 55.85m (~365 hours total)

---

In ZD we have a JPOP-Jetpack Connection tag which shows the following data:

7 Days:
5 interactions averaging 39m (~3 hours total)

30 Days:
49 interactions averaging 35m (~29 hours total)

(it is worth noting JP connection issues are _predominantly_ handled in Live Chat - so this discrepancy makes sense.

[davemart-in]

@ebinnion just cc'ing you on this one. If you have any suggestions on how to best handle this, I'd love to hear them.

[davemart-in]

@jordesign thanks so much for gathering and sharing this data! This is super helpful.

[ebinnion]

Disconnecting a site completely, or disconnecting a single user, does two things that affect user connections:

• First, it clears out the user tokens for all users, or a given user, on both the remote site and WordPress.com
• Second, it removes the WordPress.com user from the cache site on WordPress.com

Just spitballing, but we could probably provide some Calypso functionality by allowing the user to be added to the site. But, any remote calls out to the site would definitely fail. And, as-is, there would also be several notices shown to the user. So, we'd want to gate those somehow.

I'm not sure that this is a great idea. 😄 It's just the first thing that came to mind.