Request for remote features not triggering as expected

Bug Description

As reported earlier today, the requests to the /site-management/features/ endpoint appear to no longer happen on demand as of 1.70.0. While #4856 changed them to rely on a cron job, that issue still included in its ACs to also request the data on demand if it is not set yet.

This is a critical issue, as it leads to users not immediately getting access to the latest Site Kit features they should, potentially they have to wait for the cron request to fire, which is obviously not great. Right now, this can easily be tested in relation to the unifiedDashboard feature rollout to 100% - if you’re on a new site, you should have access to the unified dashboard as soon as you have completed the setup flow, but that appears to not be the case because the remote features request is not triggered.

It is unclear whether the PR #4922 for the above issue introduced a problem here, but that’s worth double-checking. We should also verify that this works as expected in 1.69.0, to further narrow down whether it’s related to the above change.

---

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

Acceptance criteria

• The /site-management/features/ request should still happen as soon as the site is connected if no googlesitekit_remote_features transient data is set yet.
• That is regardless of the cron job, that cron job is just there to update it later.
• The cron action hook should use the googlesitekit_ prefix.

Implementation Brief

• Update the get_transient_features event hook name to be prefixed with googlesitekit_
• Update the conditional logic in Authentication::get_transient_features
  • bail early if not using the proxy
  • only make the request to get_features if credentials are present

Test Coverage

• Add PHPUnit test coverage for above changes

QA Brief

QA

• Set the Force enabled feature flags to ‘Do not override’ in the Google SK Tester Plugin. In a fresh WP install, activate SK. Verify that the Unified Dashboard is enabled.

---

QA: Eng

• Check if the code meets the AC/IB and that the new PHP Unit Tests are sufficient.
• Configure HTTP proxy on your local machine following instructions in the engineering workflow doc to use mitmproxy or use an equivalent tool to inspect outgoing HTTP requests.
• Create a fresh install of WP (or Reset Site Kit and clear all site data in the browser) and install + activate the SK plugin.
  • Verify that no requests were made to the /site-management/features/ endpoint.
  • Verify that the DB has a new cron job - googlesitekit_cron_update_remote_features.
  • Verify the old get_transient_features cron hook is not added.
  • Verify that the _transient_googlesitekit_remote_features option is not present in the wp_options table.
• Now setup site kit. While doing so:
  • Verify that a request is made to /site-management/features/ and the response contains the enabled features.
  • Verify that the _transient_googlesitekit_remote_features option is present in the wp_options table. Ignore this step if #4861 has already been merged.

Changelog entry

• Ensure request for remote features is made on site connection.

[felixarntz]

Aside: We shouldn’t use an unprefixed action for cron hooks, see https://github.com/google/site-kit-wp/pull/4922/files#diff-fd8b5c88edabac5e94ebf3751d5ea639f149dec14a1296a74b6890617a92bf2dR282-R284 - similar to all actions or filters that we add, they must have a plugin-specific googlesitekit_ prefix.

I don’t think that’s related to the problem here, but worth noting as it can easily cause conflicts.

cc @jimmymadon @techanvil

[hussain-t]

QA Verified ✅

• Verified that the new PHP Unit Tests are sufficient.
• When the plugin is installed and activated before the setup, verified the following:
  • No requests were made to the /site-management/features/ endpoint.
  • The DB has a new cron job - googlesitekit_cron_update_remote_features.
  • The old get_transient_features cron hook is not added.
  • The _transient_googlesitekit_remote_features option is not present in the wp_options table.
• After the setup verified the following:
  • A request is made to /site-management/features/ and the response contains the enabled features.