Compatibility check: add service & API connection detection

Feature Description

When users first set up Site Kit, the plugin checks that the user’s setup is completely compatible with Site Kit. We can improve these checks by adding a connection check to services the plugin depends on. If the connections fail (because of a firewall for example), we should inform the user they may not be able to use Site Kit.

Existing compatibility check.

Currently, the CompatibilityChecks component is responsible for checking compatibility and includes checks for caching (which prevents tag verification from working) or a localhost domain.

Adding connection tests

We can extend these checks to also verify the user can connect to required services:

• Site Kit Service (aka “the proxy”): test a request to a route on the service work? (eg. https://sitekit.withgoogle.com/site-management/setup/)
• Oauth URL: test a request to https://myaccount.google.com/ (or the oauth route https://accounts.google.com/signin/oauth/) work?
• Search console and other APIs: Site Kit needs access to APIs from PHP - we should check a request to https://www.googleapis.com or a specific API endpoint from PHP. The server side check is important because it is possible the client can connect while the server is blocked.
• AMP project - test a request to cdn.ampproject.org. The service/proxy currently uses AMP, if the user is unable to connect to cdn.ampproject.org Site Kit will not work for them.

A response status check should be sufficient for testing. When we detect an issue we can warn the user that their setup may not be compatible with Site Kit.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Site Kit should issue a server-side request to https://www.googleapis.com/analytics/v3/management/accounts (essentially any Google API endpoint requiring OAuth) - i.e. ( new Google_Service_Analytics(...) )->accounts->listManagementAccounts() - with an arbitrary access token. If the request fails with an error code other than 401 (e.g. cURL error), it should display message: "Looks like your site is having a technical issue with requesting data from Google services. {new line} To get more help, ask a question on our support forum and include the text of the original error message: {new line} {errorMessage}" (Note that 401 is the expected error response here, since the token is invalid.)
  • This should happen via a new REST route that uses the regular OAuth client, but then attaches an arbitrary access token for the request. This could theoretically be tried without any access token too, but this would have the PHP client try out a different method of authorizing, so providing an invalid access token should be more straightforward.
• Site Kit should issue a client-side request to https://accounts.google.com/o/oauth2/auth. On failure it should display message: "Looks like the Google authorisation service is restricted in your region which would prevent you from connecting to Google services via Site Kit. {new line} To get more help, ask a question on our support forum and include the text of the original error message: {new line} {errorMessage}"
• Site Kit should issue a client-side request to https://cdn.ampproject.org/v0.js. On failure it should display message: "Looks like the AMP CDN is restricted in your region, which could interfere with setup on the Site Kit service. {new line} To get more help, ask a question on our support forum and include the text of the original error message: {new line} {errorMessage}"

Implementation Brief

• Add a new Core\Util\Health_Checks class
  • Registers a new core/site/data/health-checks endpoint, returns an object of results for various checks.
    Each check has its own key in the response object and maps to its own results object which includes a minimum of a boolean pass, but could potentially include any other arbitrary data.
    • googleAPI: { pass, errorMsg } - tests a request to the Search Console API
  • See https://github.com/google/site-kit-wp/blob/enhance/1549-compatibility-checks/includes/Core/Util/Health_Checks.php
    Needs to be updated to use above endpoint or otherwise match ACs

assets/js/components/setup/compatibility-checks.js

• Add a new function to the list of checks to request core/site/data/health-checks (useCache: false)
  • If response.checks.googleAPI.pass === false, throw an error to display the warning in the AC
• Add a new function to the list of checks to make a fetch request to https://cdn.ampproject.org/v0.js
  • If response.ok === false throw an error to display the warning in the AC
• Follow existing convention for checks by throwing named errors when warning conditions are met
• Replace legacy dataAPI usage with googlesitekit-api

QA Brief

• Should test that a failed connection to the search.google.com will cause the checks to fail, as well as a failed connection from the client to cdn.amppproject.com.
• To test the region-specific problems, a VPN should be used to e.g. request the AMP CDN from a country like Egypt where it is currently restricted.

Changelog entry

• Detect potential problems with issuing API requests to Google services and AMP prior to setup and inform the user about it.

[felixarntz]

@aaemnnosttv IB pretty much ✅ , just let’s stick to using core/site as REST route prefix for these kinds of endpoints, I think we should use a name like core/site/data/health or core/site/data/health-checks instead.

[aaemnnosttv]

Thanks @felixarntz this should be ready for another review.

One difference from the AC is that I used the Search Console API for the test request since it’s the only API which is required for all installs, whereas not all Site Kit users may use Analytics. If it should use Analytics instead, that’s an easy change to make I just thought it would make more sense to use something that applies to all sites (even though we don’t really request that API anymore from Site Kit). Alternatively, maybe we could request something from the Site Verification API as it’s the only other module which is always active.