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


@MWDelaney: Yes. Thats right. There is no problem with new projects, only with existing ones. But Scott’s fix works.

@swalkinshaw Thanks! Worked perfectly.

Here is my version which worked without ssh into the server as we use capistrano for deployment.

1.) Remove “old” package, johnpbloch/wordpress, from composer.json
2.) composer update
3.) composer clear-cache
4.) optionally: remove files from HOME/.composer/cache/
5.) Add “new” package: composer require johnpbloch/wordpress
6.) composer update
7.) deploy new version via capistrano: cap deploy


Hi, I tried these steps with “Two packages cannot share the same directory!” error

EDIT: I got it! (I don’t need help).

Nick fix works fine for me.


I hit this today updating a recently launched site from 4.7.2 to 4.7.3. Worked fine for me using @schaetzle’s method, although I had to run this separately on local dev and then over SSH to the production server. <10 seconds of downtime.


Yes it will break, but this fix works!


I tried this, but it doesn’t work :frowning:

Updated to johnpbloch/wordpress 4.7.3,
committed composer.json + composer.lock,
deployed to production (it broke).

Then ssh as user web to production server.

  • cd /srv/www/thesite/current/
  • composer update
  • composer clear-cache
  • rm -r $HOME/.composer/cache
  • composer require johnpbloch/wordpress
  • composer update

Re-deployed again to production. - Still breaks. - Still HTTP 500.


Did you walk through these steps on your local machine or only on your production server?
And I think you forgot to remove the johnpbloch/wordpress line in your composer.json. This would be the second step in your case and is a very important one. Because the new version will only be fetched (composer require johnpbloch/wordpress) if the old one doesn’t exist anymore


Only on production server. I retry this now also on local composer files.


Please also see my previous answer. It could be that you forgot one step.
But you must follow these steps locally, too. Otherwise you will have these problems again with future deploys.


As Nick said (and worked for me), you also should do:

  • Remove johnpbloch/wordpress from composer (in development)
  • Deploy (with fail)
  • Add johnpbloch/wordpress to composer (in development)
  • Deploy (with success)


This worked! Thank you a lot!


So why does Trellis deploy task switch the current symlink to the failed install?

It even checks for an existing WordPress installation and reports it missing,
why does it still switch, causing outtime while it could have just left the old working version?

Shouldn’t this bug in Trellis deploy task be fixed to avoid surprises like this one in future?


@strarsis somethings need to be done after the deploy is “finalized” (aka symlink updated).


But looking at that, maybe some of those things can be moved before finalizing. Such as checking “WordPress Installed?”. Then if that fails, the deploy would before symlinking.

I’d be open to a PR exploring some of those changes.


Hi everyone, I’m currently working on a trellis + bedrock project with another dev and am a bit confused by what is being discussed. Could someone please break down the solution in a single post, or point me to it? I’m still relatively new to trellis + bedrock and I’m encountering this error with composer update on a local machine in /site/…

  Two packages cannot share the same directory!


 "require": {
    "php": ">=5.6",
    "composer/installers": "~1.0.12",
    "vlucas/phpdotenv": "^2.0.1",
    "johnpbloch/wordpress": "4.7.2",
    "oscarotero/env": "^1.0",
    "roots/wp-password-bcrypt": "1.0.0"

EDIT this checklist worked for me, sorry. I’ll get me coat!


Hi, I am relatively new to trellis, but I could fix the issue both on my local dev and the production by the following steps.
A review from the expert would be appreciated :slight_smile:

Start by fixing the local development env.

On your local machine:


Create a branch to fix the issue (if you prefer)

% git co -b fix-wp-repo

Edit your composer.json

% nano composer.json

by deleting the following line.

"johnpbloch/wordpress": "^4.7",

Save the file, and apply the change on the vagrant host.

% vagrant ssh
$ cd /srv/www/YOUR_HOST_NAME/current
$ composer update
$ composer clear-cache
$ composer require johnpbloch/wordpress
$ exit

Commit the change on composer files.

% git add .
% git commit -m ‘Fix the wordpress repo change’
% git push origin fix-wp-repo

Merge the fix above on the github or wherever you are hosting your repo.
Next, fix the production. Make sure that USER_NAME has a sudo privilege.

$ cd /srv/www/YOUR_HOST_NAME/current
$ sudo -u web nano composer.json 

Delete the following line.

"johnpbloch/wordpress": "^4.7",

then save the file.

$ sudo -u web composer update
$ sudo -u web composer clear-cache
$ sudo -u web composer require johnpbloch/wordpress

If you could successfully update the production, exit back to your local machine.

$ exit

and make sure that your deploy work for the production.

% ansible-playbook deploy.yml -e "site=YOUR_HOST_NAME env=production"


I still had problems deploying after things were working again on dev, getting the Two packages cannot share the same directory error on deploy. After some digging I found out it was actually Trellis that was causing the problem by copying the vendor folder from the current release to the new release folder.

I fixed this by (temporarily) commenting out the “Check if project folders exist” and “Copy project folders” tasks in roles/deploy/tasks/build.yml. Hope this helps anyone.


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?


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.


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.


This worked for me. Thank you!


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