Trellis deploy - composer uses old version of package - loading from cache

when I deploy with trellis the staging environment to which I am deploying end up not having the latest version of some of my custom packages. the wp plugin packages are git repos and in github they are up to date, however after the deployment completes successfully the latest version of the plugin is not installed, it is not the same as in local environment

when i ssh into the staging server and run composer install from there the plugins in question are marked with ‘loading from cache’. could this be the problem?

1 Like

I’ve had the same problem. It tends to happen for me if the plugin is updated via WordPress instead of via composer. I changed the trellis default setting to show plugin updates on remote environments, because I want to make sure everything gets updated properly. The only fix I’ve found is to SSH into the remote server and run:

  1. sudo su web
  2. composer clearcache

I then usually have to delete the plugin folders and run a deploy. That solves the problem for me if it comes up.

Since the plugins you’re talking about are on Github, try changing the version to “dev-master” when requiring it in composer.json.

3 Likes

Here’s what came to mind. Not sure if it applies to you…

I think your deployment would typically grab the composer.lock from the repo specified and install the versions in that lock file. You might double-check that the lock file in your repo has the plugin versions you intend.

For example, suppose you run composer update on your local dev and get all the latest plugin versions on local, then deploy without committing that newly updated composer.lock file to your repo. Then the deploy’s composer install on staging would install the older versions indicated in the repo's out-of-date version of composer.lock.

Same issue here, for the WP Migrate Pro plugin. It happens on two trellis instances.

Locally, composer updates correctly the plugin to the latest version.

On the remote server, it does not, although the composer.lock file does mention the correct (latest) versions.

I’ve tried ssh-ing on the remote server and composer clear-cache then committing the composer.json + composer.lock files (after checking it had the correct versions), then re-deploying.

To be honest, I only have this issue with that specific plugin so I’m not exactly sure this is related to trellis.

For the record, here is the package.json file (trimmed):

{
		"type": "package",
		"package": {
			"name": "deliciousbrains/wp-migrate-db-pro",
			"type": "wordpress-plugin",
			"version": "1.8.1",
			"dist": {
				"type": "zip",
				"url": "https://deliciousbrains.com/dl/wp-migrate-db-pro-latest.zip?licence_key=my-license&site_url=my-site.tld"
			},
			"require": {
				"composer/installers": "~1.2.0"
			}
		}
	}, {
		"type": "package",
		"package": {
			"name": "deliciousbrains/wp-migrate-db-pro-media-files",
			"type": "wordpress-plugin",
			"version": "1.4.9",
			"dist": {
				"type": "zip",
				"url": "https://deliciousbrains.com/dl/wp-migrate-db-pro-media-files-latest.zip?licence_key=my-license&site_url=my-site.tld"
			},
			"require": {
				"composer/installers": "~1.2.0"
			}
		}
	}],
	"require": {
	    "php": ">=5.6",
		"composer/installers": "~1.2.0",
		"vlucas/phpdotenv": "^2.0.1",
		"johnpbloch/wordpress": "^4.9",
		"oscarotero/env": "^1.0",
		"roots/wp-password-bcrypt": "*",
		"deliciousbrains/wp-migrate-db-pro": "*",
		"deliciousbrains/wp-migrate-db-pro-media-files": "*"
	},

Try typing in an actual version number rather than * in the require line.

I should have mentioned it, but I did try that too. Including changing the url to replace “latest” by the version number (mentioned in the plugin’s documentation).

Are you able to download the latest version manually? Could their system be messed up and delivering the wrong version, or not announcing the new version properly?

Oh! Here’s one that bites me more often than I’m proud of: is there any chance your local and production are on different branches and you forgot to merge before deploying?

That’s happens to me embarrassingly often.

Nice idea. I tried it and both urls do return the correct version.
Note that the update via composer does work on the local setup, just not on the remote environment.

Does it install the correct version if you SSH into your remote server and run composer install manually?

I tried this:

  1. ssh into remote server
  2. sudo -i
  3. rm composer.lock
  4. composer clear-cache
  5. composer install

No go :(. Perhaps the clear-cache does not delete correctly ? It is weird that the composer.lock file correctly references the latest versions.

IIRC Trellis doesn’t use sudo to install composer dependencies, so maybe (???) you’re clearing the “wrong” cache when you run composer clear-cache as sudo.

My other guess would be that your problem has to do with the fact that you’re using the package repository type, which can get a bit dicey in my experience. The official documentation describes it a bit better. These specific points that it calls out may be relevant:

  • Composer will not update the package unless you change the version field.
  • Composer will not update the commit references, so if you use master as reference you will have to delete the package to force an update, and will have to deal with an unstable lock file.

When I find myself needing to include plugins that don’t have wpackagist entries (i.e. premium things) I’ve gotten in the habit of just setting up and maintaining my own BitBucket repos that track the official product versions. There’s a little overhead with updating the repos when new versions come out, but it allows me to make better native use of Composer features like version constraints.

2 Likes

For the record, Jeff, from DeliciousBrains, suggested I try this:

Have you tried removing the existing plugin files? I’m wondering if there’s some sort of permissions issue where composer can’t overwrite what’s there.

… So I went on the Dashboard to desactivate the plugin before deleting it manually… Only to find out it had been updated to the latest version !
It must have been a caching issue where the Dashboard kept showing the update notice. The last thing I tried (and that must have solved it) was following @alwaysblank suggestion to clear the cache as the web user, and not as sudo.

1 Like