wp-rocket icon indicating copy to clipboard operation
wp-rocket copied to clipboard

PSR-4 warnings when installed via Composer

Open ethanclevenger91 opened this issue 1 year ago • 9 comments

Describe the bug Composer is yelling about a variety of classes not conforming to PSR-4 autoloading standards:

Class ActionScheduler_AsyncRequest_QueueRunner located in ./web/app/plugins/wp-rocket/inc/Dependencies/ActionScheduler/classes/ActionScheduler_AsyncRequest_QueueRunner.php does not comply with psr-4 autoloading standard (rule: WP_Rocket\ => ./web/app/plugins/wp-rocket/inc). Skipping.

I don't believe this has any actual impact on functionality, since I'm assuming that the plugin is not dependent on my autoloader to make sure all required files are loaded.

To Reproduce Steps to reproduce the behavior:

  1. Set up a WordPress site using Composer to manage plugins a la Bedrock
  2. composer require wp-media/wp-rocket
  3. See error

Expected behavior No warnings.

Additional context Current versions:

  • wp-media/wp-rocket:v3.16.2.1
  • Composer 2.7.7

Acceptance Criteria (for WP Media team use only) Clear instructions for developers, to be added before the grooming

ethanclevenger91 avatar Jul 29 '24 23:07 ethanclevenger91

@ethanclevenger91 Thanks for creating the issue! @MathieuLamiot What do you think about this one?

piotrbak avatar Jul 31 '24 18:07 piotrbak

Hello, this is a known issue that we can't really fix: the issue comes from one of our dependency, not our code directly. ActionScheduler does not use namespace.

@piotrbak for more internal details: https://wp-media.slack.com/archives/C43T1AYMQ/p1720021115437999?thread_ts=1720021115.437999&cid=C43T1AYMQ

MathieuLamiot avatar Jul 31 '24 19:07 MathieuLamiot

Would it make sense to move that dependency into its own directory then so that it isn't subject to the autoloader rules defined here?

ethanclevenger91 avatar Jul 31 '24 19:07 ethanclevenger91

Pinging @Tabrisrp for a second look

MathieuLamiot avatar Jul 31 '24 20:07 MathieuLamiot

Re-opening following QA getting the following error when updating to the new version, because of the path change:

[12-Aug-2024 13:11:38 UTC] PHP Fatal error:  Uncaught Error: Class 'ActionScheduler_Lock' not found in /var/www/rocketlabsqa.ovh/htdocs/wp-content/plugins/wp-rocket/inc/Dependencies/ActionScheduler/classes/abstracts/ActionScheduler.php:29
Stack trace:
#0 /var/www/rocketlabsqa.ovh/htdocs/wp-content/plugins/wp-rocket/inc/Dependencies/ActionScheduler/classes/ActionScheduler_QueueRunner.php(106): ActionScheduler::lock()
#1 /var/www/rocketlabsqa.ovh/htdocs/wp-includes/class-wp-hook.php(324): ActionScheduler_QueueRunner->maybe_dispatch_async_request()
#2 /var/www/rocketlabsqa.ovh/htdocs/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#3 /var/www/rocketlabsqa.ovh/htdocs/wp-includes/plugin.php(517): WP_Hook->do_action()
#4 /var/www/rocketlabsqa.ovh/htdocs/wp-includes/load.php(1280): do_action()
#5 [internal function]: shutdown_action_hook()
#6 {main}
  thrown in /var/www/rocketlabsqa.ovh/htdocs/wp-content/plugins/wp-rocket/inc/Dependencies/ActionScheduler/classes/abstracts/ActionScheduler.php on line 29

Steps:

  1. Install and activate 3.15.10/3.16.3 zip
  2. After sitemap is fetched and started to process URLs
  3. Delete the update plugins transient
  4. update to 3.16.4 alpha
  5. check debug.log

This is likely happening because action scheduler actions are still running while we update, and one of the calls is trying to access the old path.

To be confirmed: is the update done with the WordPress update system, or through a branch switch on git?

remyperona avatar Aug 13 '24 13:08 remyperona

It'll not be part of the 3.16.4. There are fatal errors related to this change when actions are running during the update. Slack convo: https://wp-media.slack.com/archives/CUT7FLHF1/p1723464013473519

piotrbak avatar Aug 13 '24 14:08 piotrbak

Could this ticket possibly re-opened as the original issue is still present after the revert done in August?

The warnings popping up during deployment is still an ongoing issue, at least as of today.

cleverington avatar Jan 03 '25 18:01 cleverington

@remyperona Any chance there'll be another stab at this?

ethanclevenger91 avatar Apr 17 '25 17:04 ethanclevenger91

Please notice that inc/Engine/WPRocketUninstall.php also violates PSR-4 and it seem to be the code owned by WP-Rocket itself.

Autoloader issues can be solved by adding these lines in composer.json:

"autoload": {
    "exclude-from-classmap": [
        "/wp-content/plugins/wp-rocket/inc/Dependencies/ActionScheduler",
        "/wp-content/plugins/wp-rocket/inc/Engine"
    ]
}

FlyingDR avatar Oct 17 '25 12:10 FlyingDR