Wordpress-ios: Receiving Jetpack site error for self-hosted sites

[diegoreymendez]

We have two reports now or user’s receiving the following error message when trying to connect their self-hosted site (no Jetpack connection) to the iOS app:

We're not able to connect to the Jetpack site at that URL. Contact us for assistance.

The fact that we’re getting a Jetpack error for a site that has not been connected to Jetpack seems really odd. We’ve confirmed with users that they are using the log in via self-hosted site address route and not going through the WordPress.com flow. We’ve also asked them to remove and re-install the app. One user has replied saying this did not change anything.

Ref: p4a5px-2nT-p2

[diegoreymendez]

The issue seems to be that:

• When a site has Jetpack enabled; and
• When you're trying to add that site through XMLRPC

ANY failure in guessing the XMLRPC URL is reported as a Jetpack error.

Technical Details

It seems like the reason behind this issue is that we are checking for errors in discovering Jetpack sites and that the logic to check for that completely ignores the actual error returned by the service call. Instead we simply test for a key in the error's userinfo, which we set ourselves (with no relation to the error being reported here).

Final Thoughts / Next Steps

I'm not sure what a Jetpack discovery error is, or who's our target audience. I have a feeling the code needs either more clarity, or to be simplified. Alternatively, we can document what Jetpack discovery is, how it works, and consider a fix for its verification logic.

On my end: I can't see any situation where the Jetpack error logic above makes sense. If we can't find a use case to support it, my suggestion would be to remove that logic entirely.

[diegoreymendez]

cc @aerych, @astralbodies, @mindgraffiti ^

[aerych]

It seems like the reason behind this issue is that we are checking for errors in discovering Jetpack sites and that the logic to check for that completely ignores the actual error returned by the service call.

Yep yep. Some background on the reason for the check can be found in the thread here: p7DTBH-7B-p2

If I remember correctly, we wanted to send the user to Jetpack support regardless of the error, whether its related to Jetpack per se or not. Details about the error are not shown partly because we were trying to make login as simple as possible (and error messages can be confusing), and because we'd still rely on the Jetpack HE to help sort out any issues. The theory being a live person providing help is more likely to result in a successful login than doing it on your own with an error message of dubious value.

Relevant PR: https://github.com/wordpress-mobile/WordPress-iOS/pull/7378
Commits:

• 1e996f8fbe99c318b0b866d1ab9a59b784c75c1e
• eebb76beb62d76db854f2e81881613b461d87e6e

[elibud]

We should not direct users to Jetpack support/mention Jetpack at all if they don't have it installed in their site though, right?

[diegoreymendez]

Yep yep. Some background on the reason for the check can be found in the thread here: p7DTBH-7B-p2

If I remember correctly, we wanted to send the user to Jetpack support regardless of the error, whether its related to Jetpack per se or not. Details about the error are not shown partly because we were trying to make login as simple as possible (and error messages can be confusing), and because we'd still rely on the Jetpack HE to help sort out any issues. The theory being a live person providing help is more likely to result in a successful login than doing it on your own with an error message of dubious value.

Thanks a ton for the background @aerych. Makes a lot more sense to me now.

Please forgive me in advance if this sounds too blunt - that's not the intention. I've been typing for a while trying to come up with good words to express a point, but I feel like clarity may be best here! :D

This looked like a bug to HEs, to @elibud and to me (probably because there's no easy way to tell this isn't a bug). I have the feeling to some degree that our approach (report all errors as a Jetpack error) may not be the best.

Thoughts? Anything we can do to make this better... maybe add a very clear comment referencing this issue?

[diegoreymendez]

We should not direct users to Jetpack support/mention Jetpack at all if they don't have it installed in their site though, right?

From what I'm seeing this only happens if the site has Jetpack enabled. I think the core of the "problem" with this is that this is intentional, but felt like a bug since both HEs and I weren't aware of it (that's my understanding).

[diegoreymendez]

Another possibility could be to let the person know that there was a problem, but that they can use Jetpack instead, since the site supports it - instead of saying there was a problem with the Jetpack connection (ie: maybe a clearer error message is what we need).

[aerych]

We should not direct users to Jetpack support/mention Jetpack at all if they don't have it installed in their site though, right?

From what I'm seeing this only happens if the site has Jetpack enabled

Yep, and yep. We query a wpcom rest endpoint to see if Jetpack is installed. We trust the response from the endpoint

I have the feeling to some degree that our approach (report all errors as a Jetpack error) may not be the best.
Thoughts? Anything we can do to make this better... maybe add a very clear comment referencing this issue?

I'm open to whatever. Since this is a support feature it might be good to post something on the requests or guild p2 (cc Jetpack support) to see whether this is still something we want, and if so, what makes sense to them. (I've pinged Anne as well.)

[diegoreymendez]

@aerych - From what I'm seeing all the reported sites have hasJetpack: true, but they also have isJetpackConnected: false.

I think it may make sense to test against that key instead. Thoughts?

Let me know if that sounds fine and I'll move ahead.

[aerych]

I think it may make sense to test against that key instead.

That's a good question for Jetpack support but I think probably any user that has hasJetpack: true is one we'd want to send to support. They are a Jetpack user even if its not connected. I think? Not sure what the support rules are there.

[designsimply]

The fact that we’re getting a Jetpack error for a site that has not been connected to Jetpack seems really odd.

I have not been able to replicate this in my testing so far. Today I tried several self-hosted sites, some with no Jetpack plugin at all and some with hasJetpack: true and isJetpackConnected: false, and was unable to replicate the problem where the error “We’re not able to connect to the Jetpack site at that URL” appears when adding a non-Jetpack site to the WPiOS app while logged in.

[designsimply]

Okay. Now I understand that the problem is not that Jetpack is installed and inactive or disconnected, the problem is that the affected sites have something going on that's making it so when the app attempts a connection it's not getting through AND the logic for what error to show is reporting it as Jetpack when it should not be doing that. So this issue is about fixing the logic for the error. After that is fixed, we will still need to check the app logs for affected sites to see what specific errors they are facing and help them individually.

[diegoreymendez]

@designsimply - We can actually start checking the logs even now. But you're right in that this is kind of a double issue: there's a real error for those sites that'll be in the log files, and WPiOS is misreporting it as always being a Jetpack error.