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

Adding single quotes made it work perfectly, thank you!

1 Like

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

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.

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

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?

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?

I cannot test anymore because I’m actually with staging environment and nothing is in production yet, so I fixed by removing the entire item folder from the server and ran again the deploy, but if you are in production and you don’t want to make site unavailable, I’d try this way:

  1. go inside the server
  2. go to last release folder
  3. make a new copy (/<releasedate>_fix/ eg) and work on it
  4. remove vendor folder (I fixed in this way locally) and/or wp folder
  5. run composer install
  6. restore this new release folder with the original name
  7. make deploy again

Try this and you shouldn’t make down and without risk to leave site down because deploy goes in error :slight_smile:

Staging and production should be functionally identical; if this process works on one it should work on the other.

If you (you, anyone reading this) are having difficulty with the process @fullyint explained above, make sure you illustrate how your set up might differ from the vanilla Trellis setup outlined in the Trellis docs.

Does anyone know if an existing site will be affected if the server is provisioned prior to applying the fix suggested by @fullyint?

Answering my own question: I did not have any problems running the wordpress-setup and letsencrypt tags.

Hi everyone! We just got tangled in this too.

Since we have multiple language packs, we had to commit a clean composer.{json,lock} to each machine.

We did this for WordPress core, for the core language packs and for plugins that had language packs. Meaning, for each path that was shared among packages, we had to commit the clean up, and then commit the packages back again. This seemed to work fine for staging, so we repeated the steps for production.

its working now flawlessly. thanks everyone for their contributions.

p.

Hi guys, it started to do the same thing for me on my staging environment.

It has the same problem even with a newly provisioned instance.

Is it just the composer install or does it have anything to do with wordpress-install task that is not present in the server.yml (I know that probably won’t be the case, but I’m trying to think of different ipothesis).

I attempted to clear the composer cache, reinstalled manually or with the task itself but no success.

Thoughts?

I’m starting to have the same problem when running deploy now.

500 and site goes down. Manually ssh into the server cd /srv/www/example.com/current

and running

wp core download
Downloading WordPress 4.7.3 (en_US)...
Using cached file '/mnt/persist/home/deploy/.wp-cli/cache/core/wordpress-4.7.3-en_US.tar.gz'...
Success: WordPress downloaded.

Gets the site up and running.

Somewhere in the deploy WordPress doesn’t get installed as it should…

I noticed most of the deploy hooks have changed some in the latest version of Trellis. I will compare them to my current deploy-hooks to see if anything has changed.

Did you miss the solution in this thread? What you did isn’t going to prevent the issue from happening again on your next deploy, follow the steps here:

4 Likes

That’s work !! , Thank you <3

I had to clear the cache about 3 times, remove all folders and update composer but it end it worked. Thanks

Should we sticky this thread?

3 Likes

I am just trying to setup a new project using bedrock command:
composer create-project roots/bedrock project1

and I am getting this error :

Installing johnpbloch/wordpress (4.7.3): Cloning eef7c0520b from cache
    eef7c0520b1e7187cd2cd7540dc997c4c3b0340a is gone (history was rewritten?) 

then it crashes. I have tried clearing my composer cache. It still doesnt work. I am not sure if i can try a composer.json update as this is a new project and I dont have a composer.json. Help!!

I get:

`➜ site git:(master) ✗ composer remove johnpbloch/wordpress
Loading composer repositories with package information
Updating dependencies (including require-dev)

Removal failed, reverting ./composer.json to its original content.

[Composer\Downloader\TransportException]
The “https://wpackagist.org/p/providers-2017-03%24e01ff7afcea733ebe73329d5e0d2ef2e0f98737381c1e557813b1f77974d6028.json” file co
uld not be downloaded (HTTP/1.1 404 Not Found)

remove [–dev] [–no-progress] [–no-update] [–no-scripts] [–update-no-dev] [–update-with-dependencies] [–no-update-with-dependencies] [–ignore-platform-reqs] [-o|–optimize-autoloader] [-a|–classmap-authoritative] [–apcu-autoloader] [–] []…`