Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mdbitz opened this issue Jan 30, 2024 · 5 comments
Open

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

mdbitz opened this issue Jan 30, 2024 · 5 comments
Labels
[Package] Autoloader [Platform] Atomic [Pri] Normal [Status] Priority Review Triggered The guild in charge of triage has been notified of this issue in Slack [Status] Stale Triaged [Type] Bug When a feature is broken and / or not performing as intended

Comments

@mdbitz
Copy link
Contributor

mdbitz commented Jan 30, 2024

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

@mdbitz mdbitz added [Type] Bug When a feature is broken and / or not performing as intended Needs triage Ticket needs to be triaged labels Jan 30, 2024
@github-actions github-actions bot added [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Platform] Atomic [Pri] High [Status] Priority Review Triggered The guild in charge of triage has been notified of this issue in Slack labels Jan 30, 2024
@anomiex
Copy link
Contributor

anomiex commented Jan 30, 2024

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.

@jeherve jeherve added [Package] Autoloader Triaged and removed [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ Needs triage Ticket needs to be triaged labels Jan 31, 2024
@matticbot matticbot moved this from Needs Triage to Triaged in Automattic Prioritization: The One Board ™ Jan 31, 2024
Copy link
Contributor

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
Copy link
Member

ricardo commented Nov 5, 2024

@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
Copy link
Contributor

anomiex commented Nov 5, 2024

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
Copy link
Member

ricardo commented Nov 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Autoloader [Platform] Atomic [Pri] Normal [Status] Priority Review Triggered The guild in charge of triage has been notified of this issue in Slack [Status] Stale Triaged [Type] Bug When a feature is broken and / or not performing as intended
Projects
Development

No branches or pull requests

4 participants