critical error on this website: An error of type E_COMPILE_ERROR was caused

[jamesozzie]

Bug Description

A support topic was opened in relation to users encountering a critical WordPress error, with 2 users reporting the error coming from Site Kit.

One user has encountered this on all the sites where he has Site Kit active on. Users are unable to access their site, I suspect both front end and admin panel. Once Site Kit is re-activated after "restoring" their site via a recovery link the same issue occurs.

The error appears as below:
An error of type E_COMPILE_ERROR was caused in line 34 of the file /var/www/wp-content/plugins/google-site-kit/includes/loader.php. Error message: require_once(): Failed opening required ‘/var/www/wp-content/plugins/google-site-kit/third-party/vendor/composer/InstalledVersions.php’ (include_path=’.:/opt/remi/php73/root/usr/share/pear:/opt/remi/php73/root/usr/share/php:/usr/share/pear:/usr/share/php’)

There have been other mentions of this on social media. awaiting further insights, unreproducible in support so far.

Support Topic(s):
https://wordpress.org/support/topic/error-there-has-been-a-critical-error-on-this-website-3/ - Open - no SH info

Additional Context

• Site Kit 1.38.0
• Possible multiple users impacted
• No obvious cause looking at the front end of one users site. There are ads related console errors

---

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

Acceptance criteria

• Site Kit should not try to autoload classes which are not part of the Site Kit build ZIP.

Implementation Brief

• Merge Update autoloader to make sure it loads only sitekit classes or its d… #3835

Test Coverage

• N/A

Visual Regression Changes

• N/A

QA Brief

• Verify that the autoloader used in the SK plugin doesn't include classes that start not from the Google\Site_Kit namespace.

Changelog entry

• Fix bug where other plugins using an unprefixed version of Composer could cause Site Kit to trigger a fatal error.

[felixarntz]

@eugene-manuilov @bethanylang If this is not caused by some odd edge-case situation, definitely a hot fix candidate. At a minimum, we'd need to include it in 1.39.0.

[eugene-manuilov]

@felixarntz Ok, I think I figured out what could cause this issue. Our classmap list (in the autoload_classmap.php file) contains a record for the Composer\InstalledVersions class added by composer automatically that points to the {$vendorDir}/composer/InstalledVersions.php file. The problem is that we don't include the vendor folder into our release build and therefore there is no such file on the disk when another plugin or a theme tries to use the InstalledVersions class and our autoloader tries to require that file since that class is listed in our classmap list.

// autoload_classmap.php

...

return array(
    'Composer\\InstalledVersions' => $vendorDir . '/composer/InstalledVersions.php',
    'Google\\Site_Kit\\Context' => $baseDir . '/Context.php',
    'Google\\Site_Kit\\Core\\Admin\\Available_Tools' => $baseDir . '/Core/Admin/Available_Tools.php',
    'Google\\Site_Kit\\Core\\Admin\\Dashboard' => $baseDir . '/Core/Admin/Dashboard.php',
    'Google\\Site_Kit\\Core\\Admin\\Notice' => $baseDir . '/Core/Admin/Notice.php',
    ...
);

I think we need to update our autoload_classes function to require classes only if they start with Google\\Site_Kit namespace. Something like this:

 function autoload_classes() {
 	$class_map = array_merge(
 		// Site Kit classes.
 		include GOOGLESITEKIT_PLUGIN_DIR_PATH . 'includes/vendor/composer/autoload_classmap.php',
 		// Third-party classes.
 		include GOOGLESITEKIT_PLUGIN_DIR_PATH . 'third-party/vendor/composer/autoload_classmap.php'
 	);

 	spl_autoload_register(
 		function ( $class ) use ( $class_map ) {
-			if ( isset( $class_map[ $class ] ) ) {
+			if ( isset( $class_map[ $class ] ) && substr( $class, 0, 15 ) === 'Google\\Site_Kit' ) {
 				require_once $class_map[ $class ];
 
 				return true;
 			}
 		},
 		true,
 		true
 	);
 }

What do you think? cc @aaemnnosttv

[felixarntz]

@eugene-manuilov This seems like a rather critical fix to push. Wouldn't it be more appropriate to provide a file_exists check though? Nevermind, on second thought I agree we should limit it to Site Kit classes only.

Can you get a PR up for this against main? If we want to push as a hotfix, the change may be simple enough so we can just modify the latest ZIP.

[eugene-manuilov]

@felixarntz PR #3835 is created.

[felixarntz]

@eugene-manuilov IB / PR ✅

Can you add a QA Brief? Would be good to test with one of the plugins that were reported to result in that error due to their usage of Composer. Also we need to make sure to test with the ZIP build and not a regular main or develop build.

[eugene-manuilov]

@felixarntz QAB is added. Unfortunately, we don't know which plugin uses the Composer\InstalledVersions class.

[felixarntz]

A release build to test this is available at https://github.com/google/site-kit-wp/wiki/refs/heads/release/1.38.1/google-site-kit.zip.

cc @eugene-manuilov @aaemnnosttv @cole10up

[felixarntz]

QA: Eng ✅

Due to the extra logic it's no longer possible for a non-Site Kit class to be accidentally picked up by Site Kit's autoloader. Only classes starting in Google\Site_Kit are considered.