It seems like there is an issue with the underlying package being updated, but it might be exposed by copying the vendor dir instead of just relying on a brand new composer install every time.
This was done for speed purposes and has never been an issue until now.
As @swalkinshaw linked, the project_copy_folders list has only the vendor dir by default. If you havenât customized project_copy_folders you can define the list as empty for one deploy, like in the command above. If you have customized project_copy_folders, youâll need to temporarily edit it to omit vendor. These adjustments to project_copy_folders have the same effect as @tmdkâs solution of commenting out the two related tasks.
@MWDelaney No guarantees, but this appears to work in my tests.
Local dev
# run commands in local machine Bedrock `site` dir
composer remove johnpbloch/wordpress
composer clear-cache
composer require johnpbloch/wordpress:4.7.3
# git add..., git commit..., git push...
Remote server
# run commands in local machine `trellis` dir
# edit `production` to be your <environment>
# edit `example.com` to be your site name
ansible "web:&production" -m command -a "composer clear-cache" -u web
ansible-playbook deploy.yml -e env=production -e site=example.com -e 'project_copy_folders=[]'
If you have customized project_copy_folders, just temporarily remove vendor from your project_copy_folders and run deploy.yml (instead of using -e project_copy_folders=[] in second command above).
Does not work in my case. The second command returns: `no matches found: project_copy_folders=``
I tried removing âvendorsâ but then the deploy fails :
@pixeline Thanks for reporting that. I suspect your shell is trying to use the square brackets [] for globbing/pattern matching. Iâve added single quotes around project_copy_folders=[] in the example commands above to hopefully avoid the problem. Could you try this:
Just had two sites with this issue. And though I decided to kill one of the projects as I no longer needed it this worked for the other one just fine. Just some other boxes left now. Glad to know I was not losing it AND that there is a solution!
It worked for me locally, but didnât help for staging and production.
What helped was extremely rough:
cleaning out contents of releases folder (that effectively kills the site until you re-deploy it and there will be no ability to rollback to previous releases because you delete them, be aware)
deploying afresh right after.
Itâs the dumbest and risky cowboy-style solution out there, that will make a site unavailable for a few minutes if re-deploying goes well and for unpredictable period if re-deploying fails, but it worked for me.
So, instead of remove releases and make the site unavailable, could be useful fix manually inside last release folder with composer cache or installing again wp package and then re-try deploy?
I did ansible "web:&<environment>" -m command -a "composer clear-cache" -u web, it finished successfully, but didnât help (the same âtwo packages in the same folderâ error), so how âfixing manually composer cache inside last releaseâ can be different?
I cannot test anymore because Iâm actually with staging environment and nothing is in production yet, so I fixed by removing the entire item folder from the server and ran again the deploy, but if you are in production and you donât want to make site unavailable, Iâd try this way:
go inside the server
go to last release folder
make a new copy (/<releasedate>_fix/ eg) and work on it
remove vendor folder (I fixed in this way locally) and/or wp folder
run composer install
restore this new release folder with the original name
make deploy again
Try this and you shouldnât make down and without risk to leave site down because deploy goes in error
Staging and production should be functionally identical; if this process works on one it should work on the other.
If you (you, anyone reading this) are having difficulty with the process @fullyint explained above, make sure you illustrate how your set up might differ from the vanilla Trellis setup outlined in the Trellis docs.
Since we have multiple language packs, we had to commit a clean composer.{json,lock} to each machine.
We did this for WordPress core, for the core language packs and for plugins that had language packs. Meaning, for each path that was shared among packages, we had to commit the clean up, and then commit the packages back again. This seemed to work fine for staging, so we repeated the steps for production.
its working now flawlessly. thanks everyone for their contributions.