Running into an issue with composer, and the versions of plugins it is installing.
For example, I’m using deliciousbrains plugins w3 offload and w3 migrate db pro.
Local composer file is correct, and when I run composer locally, it installs versions 1.6 of wp-migrate-db-pro, and version 1.1.4 of wp-offload-s3-pro. (Most recent at this time)
When I push to git, the hashes are correct, and then when I deploy to the server, it has old versions still installed (1.5.5 and 1.0.5 respectively)
I’ve gone ahead and deleted all the folders in releases and tried to upload again, to the same avail.
I then tried to go ahead and manually edit the composer.json file on the server to see if that was the issue, but alas it shows the correct versions there.
Going on to the server and running composer update gives me this error: [ErrorException] file_put_contents(/srv/www/staging.domain.com/releases/20160603000507/vendor/composer/installed.json): failed to open stream: Permission denied
though I’m not sure if that’s expected or not.
I’ll manually add these files to git for now, but I remain puzzled.
Some further debugging goes to show that this isn’t limited to just Delicious Brains. A few other wpackagist plugins are doing the same thing - installing correct version locally, incorrect version remotely.
That looks more like a permission error on the filesystem. Try to remove the vendor folder where composer operates and re-run composer install.
Also notice that you do not need to run composer update if you’re pushing the composer.lock file which already points composer to the production versions of the packages you need.
Just wanted to add a “me too” here. I’ve been having this issue as well, with plugins from both packagist, wpackagist, and a private repo (DB Migrate).
In my case neither local nor production were updating. Composer.json reflected the proper version numbers, composer told me there was nothing to update, but the plugins in question were not being updated.
In my case the plugins were -
DB Migrate Pro
DB Migrate Media Files
DB Migrate CLI
CMB2 (via packagist)
The SEO Framework
I was able to force the updates by running composer clearcache, then removing the entire /vendor directory, then running composer install.
I had to do this on both development and production, but everything is up to date now.
Just bumping this again… if I ever have to SSH into the live server to make changes to composer, what user should I log in as? It gives warnings running composer as root and I don’t want to break any permissions stuff…
I forked it to work with Offload S3 aswell. Provisioning works without a hitch. But when I deploy updates to stage or production it will revert to the version that was installed the first time during provisioning.
So I SSH in to the server, clear composer cache, remove vendor folder and then run sudo composer install --prefer-dist. Without the sudo I will get error messages thrown in my face about not being allowed to create folders.
It’s also a bit annoying since it grabs the latest version of the plugin no matter what, so if I provision a server later on it’ll get the latest update when dev still might be on a earlier (and vetted/tested version).
I realize this might not be an issue tied to Roots, but since I saw you posting in here Nicolo I thought I’d just try and ask here to see if you know anything about this or if you’ve experienced anything like it.
Yes that package is mine
In my experience, this is usually an issue with the composer cache. But I do not run commands on the remote server, I just rsync what I need to the servers. Unfortunately, there’s not much you can do about the versions (at least for the db migrate pro, haven’t looked into S3, sorry!) as they do not expose any parameter to request a specific version, but only expose the latest version. ACF on the other hand (from which I forked and edited my package) does provide a method to retrieve an exact version (reason why the original project works beautifully!)
Regarding your sudo issue, it feels to me like your folders have the wrong owner/permissions.
You should be able to solve that by running chmod or chown and reset those folders recursively to your owner, or at least to be writable for your user!
This is old, but hopefully this can help someone in the future. I ran into this problem today and it ended up being a problem with my php cli version. I was installing slim/twig-view which has twig as a dependency. On my local machine, running php 5.6.30, composer installed twig v1.33.2 which worked. However, my server was running php 7.1, so composer allowed twig v2.3.2 to be installed, which did not work for my application. So, one possible solution to this problem, is to check for a mismatch in the php versions running on remote v local.
