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

bedrock
1

About three hours ago, this repository which Bedrock relies on moved to https://github.com/johnpbloch/wordpress-core. Was anyone else left with an empty directory and a composer.json file where /wp used to be?

I know the new repository is supposed to be included as a dependency, but this failed the first time when updating composer.

Background on the change: https://code.johnpbloch.com/2015/07/upcoming-changes-to-my-wordpress-fork/

Update: to clarify, the package didn’t move as the old package references the new one as a dependency, so the problem is not changing the package name in Bedrock, but how to update composer effectively in development and production environments without rebuilding everything.

3 Likes
2

I was able to resolve this locally by removing "johnpbloch/wordpress": "4.7.3", from my composer file and then reinstalling it, which forced an update of the new dependencies to include johnpbloch/wordpress-core.

When deploying the update to a remote server after committing this change in Trellis, the deploy fails with a Two packages cannot share the same directory! error as the previous WP directory tries to be removed and then replaced. Running the deploy script a second time didn’t seem to fix that issue. Any guesses on how to get around that error?

5 Likes
3

Same here, unable to update Wordpress from 4.7.1 to 4.7.3. Any Ideas?

4

Same here.
Workaround from @nickkeenan worked. Thank you!

6

I’m pretty confused.

AFAIK nothing has changed for us. Bedrock uses the johnpbloch/wordpress package which still exists and works.

That package is core plus the composer installer which is needed.

I just tried Bedrock myself from scratch and it worked as it should.

7

That blog post is pretty old.

8

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
9

Still confused :thinking:

What is the “revised package”? Bedrock has used the same package since 2014.

10

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

1 Like
11

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!

12

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

13

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
14

I have the exact same problem :frowning:

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?

15
2 Likes
16

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?

17

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

18

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?

3 Likes
19

Yeah, I’m convinced it’s happening :slight_smile:

Honestly I’d probably skip all that and just try it directly on the server.

  1. Update to 4.7.3 and commit the lock file as usual
  2. Deploy, it will break?
  3. SSH into server, sudo as web user
  4. Update composer.json and remove the wp package, clear the cache, etc.
  5. 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
20

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

21

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