WordPressComSiteInfo: update setting hasJetpack from remote response

[jaclync]

Fixes woocommerce/woocommerce-ios#1113

• WCiOS PR branch for testing: [Testing only] fix signing in via site address with the latest WordPressAuthenticator version woocommerce/woocommerce-ios#1118
• WPiOS PR branch for testing: [For testing only] test WordPressAuthenticator PR branch WordPress-iOS#12170

Background

In this PR, we switched the API call to fetch site info during site address sign in flow from fetchSiteInfo to fetchUnauthenticatedSiteInfoForAddress in order to accommodate both public and private sites (fetchSiteInfo only works for public sites). However, the responses from these two calls are very different.

With fetchSiteInfo (what we called before for WP.com sites), the response is like:

{
    "ID": 161199960,
    "name": "fun testing",
    "description": "",
    "URL": "https://funtestingusa.wpcomstaging.com",
    "jetpack": true,
    ...
}

And with fetchUnauthenticatedSiteInfoForAddress, the response looks like:

{
    "urlAfterRedirects": "https://funtestingusa.wpcomstaging.com",
    "isWordPress": true,
    "hasJetpack": true,
    "isWordPressDotCom": true
    ...
}

Originally, the site info’s hasJetpack is decoded from the response’s jetpack field, but now this info lives in the response's hasJetpack field. Thus, site info’s hasJetpack field is always false.

This is not a problem in WPiOS because WPiOS does not check any other fields in the site info before proceeding to the next screen vs. WCiOS only continues when site info's hasJetpack field is true in the authenticator delegate method. That’s why the site address is not considered valid and stuck on the site address screen in WCiOS.

Changes

• Updated how we populate hasJetpack field in WordPressComSiteInfo from remote response's jetpack field to hasJetpack field
• Notes: there are more fields that are not populated correctly with the new API response (e.g. name, url, icon), but I'd like to keep this PR small to just fix the sign in issue in WCiOS

Testing

In WCiOS branch

• Sign in with site address --> should be able to complete the flow to enter a WC store

In WPiOS branch

• Sign in with site address --> should work as before

[jaclync]

I just tested on WPiOS, but signing in with site address didn't work for me on the latest develop, the testing branch, and also on the latest app store build. The error occurs on a different screen, when entering username/password after site address. Do you see the same issue, or maybe I missed something?

Update: it was due to a *.wpcomstaging.com address. It worked when I signed in with a *.wordpress.com address for my site.

[ctarda]

@jaclync I just tested with WooCommerce and for this store:

I got this error back:

To be fair, that is the same result I get when trying to log in with our develop

Also, the colour palette has changed completely, this is what we have on develop right now:

[jaclync]

@ctarda thanks for testing!

I just tested with WooCommerce and for this store. To be fair, that is the same result I get when trying to log in with our develop

Hmm are you able to sign in with the same address in production from the App Store? Also, could you try again including http:// in the address?

Also, the colour palette has changed completely, this is what we have on develop right now

Yep if we update the authenticator pod to the latest with color changes (still in beta), then we'd update the colors for the new color variables (buttonTextColor, buttonTextHighlightColor, placeholderColor etc.). I set these colors to some native colors just for testing, since I didn't know the right colors right away 😛 If we want to update the authenticator pod to a newer stable version like 1.5.3 or 1.6.0, we don't have to make the color changes.

[yaelirub]

@jaclync , I'm going to review and test soon but just a small comment on the description of this issue:

we switched the API call to fetch site info during site address sign in flow from fetchUnauthenticatedSiteInfoForAddress to fetchSiteInfo

We actually switched from fetchSiteInfo to fetchUnauthenticatedSiteInfoForAddress

[jaclync]

We actually switched from fetchSiteInfo to fetchUnauthenticatedSiteInfoForAddress

@yaelirub my bad! Just updated the PR description :)

[yaelirub]

I tested on WPiOS by checking out the branch issue/wcios-1113-authenticator-sign-in-site-address-testing
Login worked with user and password and with site.

[ctarda]

@jaclync sorry for the delay. I still can not login to store.ctarda.com, neither with nor without the scheme, but I can not do it in production either (same error)

I tested with a different site, without a subdomain and it worked.

[ctarda]

[jaclync]

thanks for reviewing & testing! 😃 merging now and closing the testing PRs right after