That blog post is pretty old.
I’m confused as well. The revised package does work – and I can see with the new package structure how we shouldn’t need to update bedrock. The new package works in the development environment if the package is removed and then reinstalled (or installed from scratch), but the change is non-trivial on say, a production server of a site that is already up and running. After updating the composer.lock file locally with the revised package and its dependencies and attempting to deploy, I’m still getting the Two packages cannot share the same directory! error on production sites – I’m assuming because both johnpbloch/wordpress and johnbbloch/wordpress-core use the same namespace as either each other or the previous commit that is currently live in production. Rebuilding from scratch there is possible, but definitely non-trivial.
Maybe this is affecting older versions of Bedrock? This site is using a version of Bedrock from a year ago when it was forked into this project.
The only theory I have is that I should force the update by removing the package from my repo, deploying without wordpress, and then immediately re-installing the package and re-deploying with the updated composer.lock. But while that works fine in development, that seems awfully risky in production and I’m wondering if there’s a better way.
Also, just in case I’m missing a best practice here – I know the goal of Trellis / bedrock is the ability to be able to spin up a new fresh install in as automated a way as possible (which usually just rocks), but in practice for me there are three things that get in the way of a seamless rebuild process in a production environment – database, uploads directory, and DNS update (if say, the fix is to build a new droplet for a site and replace the old one). So in practice, I really try to avoid rebuilding once a site is in production. If the solution is to rebuild from scratch, Is there a doc somewhere that I’ve missed where people are automating those processes?
1 Like
Still confused 
What is the “revised package”? Bedrock has used the same package since 2014.
Nothing officially documented out, but I’d search the forums. There’s been a lot of discussion on all of these topics but it would be nice for us to have official docs. Anyone can contribute to them 
1 Like
This is what’s happening for me when I attempt to deploy with: “johnpbloch/wordpress”: “4.7.3”:
I run composer update in development on an existing vagrant box and get the error:
"Loading composer repositories with package information\nInstalling dependencies from lock file\nPackage operations: 24 installs, 0 updates, 0 removals\n\n \n [InvalidArgumentException] \n Two packages cannot share the same directory!
I remove the wordpress 4.7.3 package and run composer update, then add wordpress 4.7.3 back and run composer update a second time. This time, I get a confirmation that the new package dependencies are added successfully:
Updating dependencies (including require-dev)
- Installing johnpbloch/wordpress-core-installer (0.2.1)
Loading from cache
- Installing johnpbloch/wordpress-core (4.7.3)
Loading from cache
- Installing johnpbloch/wordpress (4.7.3)
Loading from cache
Writing lock file
Then I commit this revised composer.json & composer.lock file to my git repo and production branch, and attempt to deploy these changes. I get the same error again and the deploy fails:
"Loading composer repositories with package information\nInstalling dependencies from lock file\nPackage operations: 24 installs, 0 updates, 0 removals\n\n \n [InvalidArgumentException] \n Two packages cannot share the same directory!
Some more information: Yes, this issue sounds similar to [current] Error: This does not seem to be a WordPress install. When I first deployed to my staging server and encountered this error – maybe a composer cache issue?, for whatever reason johnbbloch/wordpress-core wasn’t included - with the error above - and the site/wp directory was empty except for the composer.json and readme.md files from johnpbloch/wordpress
The version for the WordPress core composer package is fixed to 4.7.3,
so this kind of error (different package content/behaviour) never should’ve happened?
1 Like
I have the exact same problem 
right now my production server is still on 4.7.2
so i decided to put “johnpbloch/wordpress”: “4.7.2” into my composer.json
this seems to work without errors on my local development VM.
if I put version 4.7.3 I get the aforementioned error saying:
Two packages cannot share the same directory!
I don’t wanna do deploy without wordpress and immediately redeploy with wordpress. so for now I’m staying on 4.7.2.
Does anybody know what’s happening?
2 Likes
I also saw Johns Tweets. And I followed his instructions.
But the wordpress core files are not installed automatically when I run composer install/update.
Only the Forks files (composer.json and Readme.md) …
Do I need to add some new information to my projects composer.json?
For example is there a flag for considering packages that are required in other composer.json files?
It’s the same package. I doubt there’s anything you can do from the composer.json file.
I had a staging environment that I could experiment with, and I’ve found a workaround to this composer cache problem for remote environments (this is on Digital Ocean droplets running Ubuntu 14.04 in this case, though it may also work with Ubuntu 16). The issue with this solution is that the production site does go down for 5-10 minutes, so it’s really not ideal. If anyone has any suggestions like specific ansible tags to run to make the process more efficient, or a way of doing this without having the site go down or rebuilding the site, I’d love it, as I know a number of us will have to deploy this new commit on live sites.
This procedure is based on johnpbloch’s tweets about the update to the package: “delete the old wordpress package. You might also need to run composer clearcache to get rid of cached downloads/repos.”
Warning: This procedure will, at least temporarily, break your site. So don’t jump in without a parachute.
Step One: Run composer update to get the latest commit of “johnpbloch/wordpress”: “4.7.3”. Commit the change to composer.lock to your repo, and deploy changes to your existing remote server.
You get the Error: This does not seem to be a WordPress install.
Pass --path=path/to/wordpressor runwp core download.
fatal: [104.131.175.130]: FAILED! => {“changed”: false, “cmd”: [“wp”, “core”, “is-installed”], “delta”: “0:00:00.282460”, “end”: “2017-03-19 23:31:10.666699”, “failed”: true, “failed_when_result”: true, “rc”: 1, “start”: “2017-03-19 23:31:10.384239”, “stderr”: “Error: This does not seem to be a WordPress install.\nPass --path=path/to/wordpressor runwp core download.”, “stdout”: “”, “stdout_lines”: , “warnings”: }
The website goes down, and if you look the /wp directory is empty except for the composer.json file. The dependency johnpbloch/wordpress-core fails to install.
Step Two: Remove “johnpbloch/wordpress”: “4.7.3” composer package entirely, run composer update, commit the change and deploy the site to your remote server without the Wordpress package, which removes the old cached version of the package from the remote site.
Second deploy also will fail with the same error, as we’ve removed Wordpress.
Step Three: Add the “johnpbloch/wordpress”: “4.7.3” package back and run composer update.
There should be three packages installed:
Updating dependencies (including require-dev)
- Installing johnpbloch/wordpress-core-installer (0.2.1)
Downloading: 100%
- Installing johnpbloch/wordpress-core (4.7.3)
Downloading: 100%
- Installing johnpbloch/wordpress (4.7.3)
Downloading: 100%
Step Four: Commit the change to composer.lock and deploy changes.
For me, this final deploy is successful and site is back up without data loss.
@swalkinshaw is that making more sense what might be causing this issue?
3 Likes
Yeah, I’m convinced it’s happening 
Honestly I’d probably skip all that and just try it directly on the server.
- Update to
4.7.3and commit the lock file as usual - Deploy, it will break?
- SSH into server,
sudoaswebuser - Update
composer.jsonand remove the wp package, clear the cache, etc. - Run
composer require johnpbloch/wordpress
This should be roughly the same process but take way less time. I’d assume if that works then any subsequent deploy would as well.
9 Likes
Makes sense to me. I’ll give it a shot on a smaller client site. Thanks!
So for clarity, this will (might? Will?) happen on existing, already deployed sites but not for new projects, and Scott’s fix above should resolve it?
1 Like
@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
11 Likes
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 
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.