Raise minimum required version of PHP to 7.4

[aaemnnosttv]

Feature Description

While Site Kit has long supported the minimum version of PHP required by WP, recent changes in core dependencies require that we raise our minimum version to leverage features, fixes, and language compatibility updates that are only available in more recent releases.

---

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

Acceptance criteria

• The minimum required version of PHP should be updated to 7.4
• All composer dependencies should be updated
• Any infrastructure specific to older versions of PHP should be updated or removed
  • E.g. Test workflows
• Must target the release scheduled for April 22
• Check with @aaemnnosttv before merging a PR for these changes

Implementation Brief

• Update google-site-kit.php
  • In plugin header comments increment Requires PHP to 7.4
  • Update constant

    site-kit-wp/google-site-kit.php

    Line 31 in 49c312c

    define( 'GOOGLESITEKIT_PHP_MINIMUM', '5.6.0' );

• Update composer.json
  • Edit require.php to >=7.4
  • Edit config.platform.php to 7.4.33
• Update phpcs.xml, in testVersion config increment php version to 7.4-
• Update

  site-kit-wp/composer.json

  Line 31 in 49c312c

  "phpseclib/phpseclib": "*"

  package so instead of replacing everything *, it needs to have >=3.0.36, as versions bellow are added to the conflict list of SecurityAdvisory and composer update will fail
• The symfony/polyfill-intl-idn package can also be updated to higher version now, we were forced to go with current one in Update usage of abandoned package #8094 due to the php version
• After packages are updated to reflect the changes in the lock file, running php tests - only 1 test is failing at the time of writing.
  • Google\Site_Kit\Tests\Core\Authentication\Clients\OAuth_ClientTest::test_get_authentication_url test is failing as google/apiclient package version (updates to v2.14.0) and in one of the versions it changes the OAuth url path to include v2 - and in this test we are not using proxy so it is expecting https://accounts.google.com/o/oauth2/auth which will be now https://accounts.google.com/o/oauth2/v2/auth. You can see the change in this commit
  • To complete the coverage add new/same test for testing the authentication url but using proxy. More details in this comment
• Do a proper testing of OAuth redirection, and general smoke testing of the plugin
• You can check if there is some other critical change that might happened between versions of v2.12.2 and v2.14.0 in the change log. During the definition, I took a brief look, and v2 is the only one I saw, but more might surface during actual execution
• Some useful documentation for checking deprecated/changed functions - here and here

Test Coverage

• Not applicable

QA Brief

• Aside from the increased minimum which should prevent SK from being usable on older versions of PHP, a number of dependencies have been upgraded so we want to do a thorough check that all the core functionality works as expected
• No visual changes should need checking here, just behavioral
• Keep an eye out for errors in the browser console and WP debug log if possible
• It's possible the changes here have fixed deprecation notices raised on newer versions of PHP such as 8.2 so that is worth checking as well

Changelog entry

• Update minimum required version of PHP to 7.4.

[aaemnnosttv]

@eclarke1 @bethanylang @ivonac4 this one must go in 1.125.0 for release on April 22 as noted above. I've pre-assigned the release accordingly but we could potentially get started on it in the previous sprint.

[bethanylang]

Thanks, @aaemnnosttv! @ivonac4 has an Asana task that I created here for this. I've updated the due date for us to include this in Sprint 124 to be safe.

[aaemnnosttv]

• Google\Site_Kit\Tests\Core\Authentication\Clients\OAuth_ClientTest::test_get_authentication_url test is failing as google/apiclient package version (updates to v2.14.0) and in one of the versions it changes the OAuth url path to include v2 - and we are looking for and expecting https://accounts.google.com/o/oauth2/auth which will be now https://accounts.google.com/o/oauth2/v2/auth. You can see the change in this commit

@zutigrm this is something we'll want to make sure we understand the implications of. It looks like this change would only affect the non-proxy-connected case, but our other classes extend the base Client. @eugene-manuilov can you take a look if there is a significant difference between the endpoints or if there might be other changes needed on the service in making this change?

[eugene-manuilov]

Yeah, we will need to implement the new endpoints on the service side. I have added an asana task for it.
https://app.asana.com/0/1199555099685093/1206593581864922/f

UPD: I don't expect there will be needed significant changes in the current oauth2 process on the service side. We will need to add a new endpoint and bind the existing handler to it. Some changes may be needed for the callback endpoint, but that will be more clear when we start working on it.

[zutigrm]

Just to note that #8094 was merged very recently, it seems that package can be upgraded also as part of this issue

[aaemnnosttv]

• Google\Site_Kit\Tests\Core\Authentication\Clients\OAuth_ClientTest::test_get_authentication_url test is failing as google/apiclient package version (updates to v2.14.0) and in one of the versions it changes the OAuth url path to include v2 - and we are looking for and expecting https://accounts.google.com/o/oauth2/auth which will be now https://accounts.google.com/o/oauth2/v2/auth.

@eugene-manuilov @zutigrm I'm not sure this requires any change for us, since the test referenced here is using a non-proxy-connected scenario. When a site is connected to the proxy, we override the OAuth2 service which is where our endpoints are defined. See Google_Site_Kit_Client::createOAuth2Service.

My assumption is that we should be able to update that test to use the new URLs for the Google OAuth endpoints that are used when a site does not use the proxy, but we need to better understand the changes to know that no other updates would be necessary in the code base. We should probably also add a test case for the same test to use the proxy as that coverage may be incomplete.

[eugene-manuilov]

Assigning this task back to @zutigrm, since he worked on IB for it.

[zutigrm]

@aaemnnosttv

I'm not sure this requires any change for us, since the test referenced here is using a non-proxy-connected scenario. When a site is connected to the proxy, we override the OAuth2 service which is where our endpoints are defined. See Google_Site_Kit_Client::createOAuth2Service.

Indeed, thanks. I just tested connecting the Site Kit, with proposed updates from IB, and I do not see any issue, regarding the OAuth, scopes, etc.

I updated the IB to include the test with proxy per your suggestion

[aaemnnosttv]

Thanks @zutigrm – there are a few more changes we should make here.

For example, we can raise our minimum versions for some dependencies to remove ranges that support older versions of PHP. E.g. PHPUnit < 9 support PHP 7.3 and below. We can also upgrade to phpunit-polyfills v2. The polyfills version change is more important since it's a major version change – Composer will handle the others where a range is wider than we need automatically but it helps to clean it up. Other things like wp-phpunit/wp-phpunit and roots/wordpress are based on our minimum WP version than PHP.

Other than that, this is basically good to go. I'll move this forward though since the rest can be iterated on during execution.

IB ✅

[mohitwp]

QA Update ⚠️

@tofumatt I set up site kit on PHP version 7.3 with latest environment. Then using tester plugin I switched from latest to dev environment. After switching to dev environment I expected that I will not able to use site kit. But, I'm able to use site kit and also able to set up new modules. Is this expected ?

[tofumatt]

@mohitwp There's nothing in our code that actually prevents Site Kit from running on older versions of PHP, I think it'd be up to WordPress. I think WordPress will prevent you from installing the plugin if your PHP version is outdated/unsupported, but I don't think it will uninstall any existing plugins.

You can try deactivating the plugin then reactivating it AND/OR installing Site Kit on PHP 7.3, which WordPress might stop you from doing. But if it's already installed it shouldn't be an issue I think.

[mohitwp]

QA Update ✅

@tofumatt Thanks ! Currently, WP allow installing Site kit on PHP version 7.3.

• Tested on main environment.
• Verified site kit installation and functionality on PHP v7.4, v8.0, v8.2 and v8.3.
• Verified that errors which were showing on PHP v8.3 under Site kit widgets on main dashboard are not appeairng now.
• Verified that no console errors or PHP deprecated errors are now showing.

cc @wpdarren @kelvinballoo Changes involved here make significant impact on plugin. Flagging here for keeping in mind this during release QA.

[aaemnnosttv]

There's nothing in our code that actually prevents Site Kit from running on older versions of PHP, I think it'd be up to WordPress. I think WordPress will prevent you from installing the plugin if your PHP version is outdated/unsupported, but I don't think it will uninstall any existing plugins.

@tofumatt We do guard against loading the plugin if minimum versions are not met. WP does more to handle this too but that was not always the case.

site-kit-wp/google-site-kit.php

Lines 120 to 125 in 6af3955

	if (
	version_compare( PHP_VERSION, GOOGLESITEKIT_PHP_MINIMUM, '>=' ) &&
	version_compare( get_bloginfo( 'version' ), GOOGLESITEKIT_WP_MINIMUM, '>=' )
	) {
	require_once plugin_dir_path( __FILE__ ) . 'includes/loader.php';
	}

[wpdarren]

@mohitwp @tofumatt, did we complete any testing on a site on PHP 7.3 and look at the behavior on the develop/main branch? I assume the banner still appears, notifying them they need to upgrade. Does Site Kit still function for them? No errors occur on dashboards or any other functionality.

I am assuming all they cannot do is update future versions of Site Kit, but everything else should function as normal. I couldn't see any reference to this testing in the QA update or any screenshots, so I wanted to double-check.

[mohitwp]

@darren In the above comment on the ticket I mentioned that - I set up site kit on PHP version 7.3 with latest environment. Then using tester plugin I switched from latest to dev environment.
After switching plugin was working as expected. But not done deep testing on PHP version 7.3.