Fatal Error when installing WP Rocket through Packagist

[WillyReyno]

Describe the bug

The following error is shown after installing WP Rocket from Packagist:

Fatal error: Uncaught Error: Class "WP_Rocket\Addon\Cloudflare\Cloudflare" not found in /var/www/html/wp-content/plugins/wp-rocket/inc/main.php:16 Stack trace: #0 /var/www/html/wp-content/plugins/wp-rocket/wp-rocket.php(132): require() #1 /var/www/html/wp-settings.php(462): include_once('/var/www/html/w...') #2 /var/www/html/wp-config.php(109): require_once('/var/www/html/w...') #3 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #4 /var/www/html/wp-admin/admin.php(34): require_once('/var/www/html/w...') #5 /var/www/html/wp-admin/plugins.php(10): require_once('/var/www/html/w...') #6 {main} thrown in /var/www/html/wp-content/plugins/wp-rocket/inc/main.php on line 16

To Reproduce Steps to reproduce the behavior:

1. composer require wp-media/wp-rocket
2. Go to website
3. See error

Expected behavior

After installing the package I shouldn't get an error, should be able to browse my website, go to plugin page and enable WP Rocket.

Screenshots

Workaround

I do have a workaround for this, which is simply to run a composer install within the plugin. So I set that up in the scripts section of composer.json. However, I think this should be done by itself after requiring the package.

    "scripts": {
        "post-autoload-dump": [
            "cd wp-content/plugins/wp-rocket && composer install"
        ]
    },

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

[piotrbak]

@wp-media/php-team What do you think about this?

@WillyReyno Thanks for creating the issue.

[mattneal-stafflink]

@WillyReyno For some reason, in order for it to work you need to run composer update from the plugin directory after requiring it. It totally makes sense that the packages aren't within the repo, but this would be a huge extra step if you were an agency with dozens of websites deploying with composer; having to update each repo and add an extra cd web/app/plugins/wp-rocket composer update seems like a pain...or am I missing something?

[Vincent-Noben]

@WillyReyno For some reason, in order for it to work you need to run composer update from the plugin directory after requiring it. It totally makes sense that the packages aren't within the repo, but this would be a huge extra step if you were an agency with dozens of websites deploying with composer; having to update each repo and add an extra cd web/app/plugins/wp-rocket composer update seems like a pain...or am I missing something?

Hi, I work for such an international web agency that maintaince dozens of websites this way with composer and we have now stumbled upon this issue. We use automatic deploy scripts in Gitlab that run a composer update, but ofcourse do not run it in subfolders or plugin folders. So it would be greatly appreciated for this to be fixed in a future version.

Note: This came up for us now trying the 3.15.6 tag in composer. As that is the version you download at the WPRocket website. But we do acknowledge that it is not (yet?) in the "releases" list on this Github. Has it been reverted for this reason or ... ?

Edit: The error also shows when forcing version 3.15.4 which is the last release on this repo.

[psternuva]

Can confirm this problem.

Version 3.15.10 WP Version: 6.5 PHP 8.2 Composer 2.5.5

cloudflare/cf-ip-rewrite has already been installed by composer under it's vendor, but the plugin incorrectly assumes it's been installed in it's local vendor folder.

The workaround of doing composer update --no-dev inside the plugin folder does work but is in no way a solution.

[psternuva]

I believe adding the following to one's project's composer.json may also workaround the problem but have yet to test it:

"extra": {
        "installer-paths": {
           "web/wp-content/plugins/wp-rocket/vendor/$name":  ["cloudflare/cf-ip-rewrite"]

(adjust path as appropiate)

[kmwalsh]

Also just confirming this issue. We were able to work around it in local builds and when deploying by running composer install in the plugin directory. Definitely not ideal, but it did get us going.

[psternuva]

Creating a symlink of 'vendor' inside wp-content/plugins/wp-rocket/ to the real vendor directory also functons as a workaround. Less than ideal.