Open WillyReyno opened 10 months ago
@wp-media/php-team What do you think about this?
@WillyReyno Thanks for creating the issue.
@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?
@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 extracd 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.
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.
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)
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.
Creating a symlink of 'vendor' inside wp-content/plugins/wp-rocket/ to the real vendor directory also functons as a workaround. Less than ideal.
@MathieuLamiot Will need your opinion here.
When trying the composer update --no-dev
workaround I get an error about mozart not found, which makes sense as it's in the require-dev section. when moving mozart into require composer update --no-dev
works again. Otherwise I think the only working work around currently is to do the full composer install composer install
.
> "vendor/bin/mozart" compose
sh: vendor/bin/mozart: not found
Script "vendor/bin/mozart" compose handling the post-update-cmd event returned with error code 127
Describe the bug
The following error is shown after installing WP Rocket from Packagist:
To Reproduce Steps to reproduce the behavior:
composer require wp-media/wp-rocket
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![Capture d’écran 2023-10-27 à 18 32 23](https://github.com/wp-media/wp-rocket/assets/5576482/b9bf8b35-7270-4984-b4c0-eb20e55cee6d)
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.
Acceptance Criteria (for WP Media team use only) Clear instructions for developers, to be added before the grooming