Johnpbloch/wordpress moved to a new configuration and WP goes missing

bedrock
37

Did you try the solutions above i.e. first making the amends locally, then SSHing into the server and doing the same procedure, then deploying?

38

Here’s what I did:

  • Make sure composer install works locally from a fresh checkout without any problems.
  • Run composer clearcache on server(s).
  • Comment out aforementioned tasks in build.yml
  • Deploy

I guess the fix directly on server works too because it works on the vendor folder of the current release, so after doing that, copying the vendor folder to the new release won’t cause any problems on deploy.

39

For me, as posted above, this worked:

You need to first complete this on your dev environment, git commit the changes, SSH into your staging/live environment and complete the above instructions again. You can then deploy as normal.

40

This worked for me. Thank you!

1 Like
41

@nathobson Just to be clear, commenting out those tasks fixed the deploys for me :slight_smile:

I should mention that I deploy through the Trellis ansible playbook, so my fix certainly does not apply when you deploy using capistrano.

42

So it turns out Trellis is also slightly to blame here we think.

Trellis copies the vendor folder to new releases. See https://github.com/roots/trellis/blob/8666765785aa799cb6828dccf9c6f846eb975cba/roles/deploy/defaults/main.yml#L11-L15

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.

4 Likes
43

I believe this means that for the remote server (vs. local dev) these two steps should avoid downtime:

# clear composer cache
ansible "web:&production" -m command -a "composer clear-cache" -u web

# deploy (without copying `vendor` dir)
ansible-playbook deploy.yml -e env=production -e site=example.com -e 'project_copy_folders=[]'

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.

Edit: Added quotes around project_copy_folders=[]

4 Likes
44

So again, for clarity (and forgive my thickness here)…

–
To fix local environment (development)

  1. Update composer.json to remove the "johnpbloch/wordpress" line
  2. Run composer clear-cache
  3. Re-add the "johnpbloch/wordpress" (or composer require johnpbloch/wordpress)
  4. Run composer update
  5. Commit updated composer files as normal

–
To fix deployed environments (staging, production)

  1. Clear composer cache ansible "web:&production" -m command -a "composer clear-cache" -u web
  2. Deploy (without copying vendor dir) ansible-playbook deploy.yml -e env=production -e site=example.com -e project_copy_folders=[]

And everything should work fine going forward after that?

Is that correct?

1 Like
45

@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).

Edit: Added quotes around project_copy_folders=[]

44 Likes
46

Awesome. It seems to work in my tests, too. Thanks for humoring my specificity :slight_smile:

1 Like
47

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 :

rmtree failed: [Errno 13] Permission denied: '/srv/www/domain.com/ releases/20170201151109/vendor/squizlabs/php_codesniffer/CodeSniffer/Reportin g.php'

48

@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:

ansible-playbook deploy.yml -e env=production -e site=example.com -e 'project_copy_folders=[]'
2 Likes
49

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!

51

WTF?! I just wanted to deploy a simple bugfix today and then this…

Thanks guys! You saved my live!

52

Adding single quotes made it work perfectly, thank you!

1 Like
53

Thankyou everyone for solving this mystery for me. It was driving me crazy – the fix from @mwdelaney worked for me!

55

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.

56

Just tested this on a multi-site install and confirm it works too.

57

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?

58

Definitely, there should be a better way.

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?