Failed opening required -- from class-php-autoloader.php

[mdbitz]

Impacted plugin

Jetpack

Quick summary

We are seeing on the Atomic platform multiple fatal errors where the Autoloader "Failed opening required" files. The interesting aspect is that the file it fails to find can be non-jetpack plugins.

PHP Fatal error: require(): Failed opening required '/srv/htdocs/wp-content/plugins/google-listings-and-ads/src/Proxies/Tracks.php' (include_path='/:.') in /wordpress/plugins/jetpack/13.1-a.9/vendor/jetpack-autoloader/class-php-autoloader.php on line 90

PHP Fatal error: require(): Failed opening required '/srv/htdocs/wp-content/plugins/jetpack-boost/app/lib/class-connection.php' (include_path='/:.') in /wordpress/plugins/jetpack/13.1-a.9/vendor/jetpack-autoloader/class-php-autoloader.php on line 90

PHP Fatal error:  Uncaught Error: Failed opening required '/srv/htdocs/wp-content/plugins/jetpack-boost/app/lib/minify/Concatenate_JS.php' (include_path='/:.') in /wordpress/plugins/jetpack/13.1-a.9/vendor/jetpack-autoloader/class-php-autoloader.php:90
Stack trace:
#0 /srv/htdocs/wp-content/plugins/jetpack-boost/app/modules/optimizations/minify/class-minify-js.php(36): Automattic\Jetpack\Autoloader\jpf11009ded9fc4592b6a05b61ce272b3c_jetpackⓥ13_1_a_9\al3_0_2\PHP_Autoloader::load_class('Automattic\\Jetp...')
#1 /wordpress/core/6.4.2/wp-includes/class-wp-hook.php(324): Automattic\Jetpack_Boost\Modules\Optimizations\Minify\Minify_JS->init_minify('')
#2 /wordpress/core/6.4.2/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#3 /wordpress/core/6.4.2/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#4 /wordpress/core/6.4.2/wp-settings.php(643): do_action('init')
#5 /srv/htdocs/wp-config.php(83): require_once('/wordpress/core...')
#6 /wordpress/core/6.4.2/wp-load.php(55): require_once('/srv/htdocs/wp-...')
#7 /wordpress/core/6.4.2/wp-blog-header.php(13): require_once('/wordpress/core...')
#8 /wordpress/core/6.4.2/index.php(17): require('/wordpress/core...')
#9 {main}
  thrown in /wordpress/plugins/jetpack/13.1-a.9/vendor/jetpack-autoloader/class-php-autoloader.php on line 90

Steps to reproduce

Unknown -> can't reproduce on my test sites spun up on various pools.

A clear and concise description of what you expected to happen.

No Fatals errors should be triggered by Jetpack code flows.

What actually happened

No response

Impact

Some (< 50%)

Available workarounds?

No but the platform is still usable

Platform (Simple and/or Atomic)

Atomic

Logs or notes

Errors can be see in at-php-errors logstash name=jetpack

[anomiex]

I doubt this really has anything to do with Jetpack-the-plugin, or the autoloader. If I had appropriate access, I'd start the investigation by looking at these sites to see whether their copies of Boost and such are somehow missing files or have bad permissions set somehow.

[github-actions[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive for the past 6 months.
• It hasn’t been labeled `[Pri] BLOCKER`, `[Pri] High`, `[Type] Feature Request`, `[Type] Enhancement`, `[Type] Janitorial`, `Good For Community`, `[Type] Good First Bug`, etc.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[ricardo]

@mdbitz @anomiex – We were able to reproduce the error in WooPayments:

PHP Fatal error:  Uncaught Error: Failed opening required '/srv/htdocs/wp-content/plugins/woocommerce-payments/includes/multi-currency/Settings.php' (include_path='/:.') in /srv/htdocs/wp-content/plugins/jetpack/vendor/jetpack-autoloader/class-php-autoloader.php:108

More details: p1730814615547449-slack-CGGCLBN58

TL;DR: The error happens once when updating the plugin. The new version had a directory moved, and the classes in this directory are PSR-4 autoloaded.

Any ideas on the best way to fix this?

[anomiex]

Once when updating the plugin is a documented caveat of the autoloader, and likely would apply to most non-Jetpack autoloaders too.

The solution for that is for the plugin to avoid triggering autoloading of the moved classes in the update request after the update has happened. Failing that, they'd need to include a stub at the old path that loads from the new path (see this for example).

[ricardo]

Thanks for the clarification @anomiex. The issue was happening because a hook was calling an autoloaded class after the upgrade process. Since the move to a new path is not really important for us, we opened a PR to fix the issue by maintaining the autoloaded paths.