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

swalkinshaw · March 19, 2017, 11:01pm

It’s the same package. I doubt there’s anything you can do from the composer.json file.

nickkeenan · March 19, 2017, 11:50pm

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/wordpress or run wp 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/wordpress or run wp 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?

swalkinshaw · March 20, 2017, 12:00am

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.3 and commit the lock file as usual
Deploy, it will break?
SSH into server, sudo as web user
Update composer.json and 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.

nickkeenan · March 20, 2017, 12:03am

Makes sense to me. I’ll give it a shot on a smaller client site. Thanks!

MWDelaney · March 20, 2017, 4:16am

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?

schaetzle · March 20, 2017, 8:21am

@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

aitor · March 20, 2017, 9:12am

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.

nathobson · March 20, 2017, 12:35pm

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.

Twansparant · March 20, 2017, 1:00pm

Yes it will break, but this fix works!

strarsis · March 20, 2017, 3:38pm

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.

schaetzle · March 20, 2017, 3:41pm

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

strarsis · March 20, 2017, 3:48pm

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

schaetzle · March 20, 2017, 3:51pm

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.

aitor · March 20, 2017, 3:52pm

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)

strarsis · March 20, 2017, 4:17pm

This worked! Thank you a lot!

strarsis · March 20, 2017, 4:18pm

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?

swalkinshaw · March 20, 2017, 6:56pm

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

See https://github.com/roots/trellis/blob/master/roles/deploy/hooks/finalize-after.yml

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.

drawcardau · March 21, 2017, 2:06am

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/…

[InvalidArgumentException]
  Two packages cannot share the same directory!

composer.json:

 "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!

goodpic · March 21, 2017, 6:34am

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

Start by fixing the local development env.

On your local machine:

% cd PATH_TO_YOUR_PROJECT/trellis

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.

% ssh USER_NAME@YOUR_PRODUCTION_IP
$ 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"

tmdk · March 21, 2017, 10:17am

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.