Wordpress not installing with existing composer.lock file

[YarGnawh]

I'm trying to automate my deployments, but I'm noticing when there's a composer.lock file in the project root, when I run composer install, the wordpress-install-dir only has the composer.json and readme.html files. It doesn't actually install wordpress-core. Rather than ignoring the composer.lock file, is there a way to force composer to reinstall wordpress-core?

So with a composer.lock file present, this is the result of running composer install

and if I delete the composer.lock file, running composer install gives me this

Though deleting the composer.lock file fixes the issue, it seems like it's best practice to commit the composer.lock file (http://stackoverflow.com/questions/12896780/should-composer-lock-be-committed-to-version-control)

Additional example:

• Download johnpbloch/wordpress-project
• Run composer install. It'll install wordpress core in public/wp.
• Commit the project , including the composer.lock file. Note: inside .gitignore, there's a line for public/wp,
• Clone a fresh copy of the repo (with the composer.lock file)
• Run composer install
• Note that it does not install wordpress core to public/wp, just the composer.json and readme.html

[lesterchan]

I am getting the same issue as well!

[ocean90]

Ugh, can confirm this issue.

[BoShurik]

Looks like now you have to use johnpbloch/wordpress-core package instead of johnpbloch/wordpress

[lesterchan]

@BoShurik I tried both, there is no diff. Removing the composer.lock file works

[ocean90]

Removing the package and adding it back after clearing the cache seems to work.

See https://twitter.com/johnpbloch/status/843118839843962881 and https://twitter.com/schaetzle/status/843740809165987841

[YarGnawh]

@ocean90 thanks! removing and adding it works. though it's far from ideal :neutral_face:

[ethicka]

This broke an install for me last night when I deployed an update. Does anyone know if we have to run these composer commands on the server as well or just locally and the .lock file fixes this on the next deploy?

[wdeer]

I can also confirm that I was having the exact same issue and that simply removing the composer.lock file fixes this particular issue while leaving "johnpbloch/wordpress": "4.7.3" in my composer.json

[chris-schmitz]

Hey everyone,

I was running into this issue as well. When I dug into what was going on, it turns out whoever initially set up the project added the wordpress dependency to the composer.json like so:

"johnpbloch/wordpress": "*",

This is telling composer "pull any newly released code". There must have been a major version release (i.e. a v5, a release that included breaking changes) and the breaking changes, you know, broke our project.

Here are the steps I went through to fix the issue:

• Identified the version of wordpress that our project was previously running at.
  • You can find this by looking for johnpbloch/wordpress in your composer.lock file.
  • If you've already blown away your lock file (like I had) you can look through your git history, a co-worker's lock file, a server's version, etc.
• Update your composer.json file to use a version number pattern that doesn't include breaking changes for your version.
  • e.g. if you're lock file says you were using 4.7.3, use the pattern "johnpbloch/wordpress": "4.7.*".
• Delete your vendor folder.
  • If you don't you may get an error that say something to the effect of "you can't have two packages in the same folder" (sorry I can't remember the exact text).
• Run a composer install.

This should pull down your dependencies again and install the older version of the wordpress package.

If you want to learn more about semantic versioning and why it broke my install (and maybe yours) check out http://semver.org.

[YarGnawh]

Here's a slightly improved version of the fix:

# Using jq to parse composer.lock (https://stedolan.github.io/jq/)
# Try to get the committed version or fallback to *

wp_version=$(jq` -r '.packages | map(select(.name == "johnpbloch/wordpress")) | .[0]?.version // "*"' composer.lock)

composer remove johnpbloch/wordpress
composer clear-cache
composer require johnpbloch/wordpress:${wp_version}
composer update

[chris-schmitz]

This is a decent solution @YarGnawh, though considering this issue for people may be stemming from a lack of understanding of the composer file, semantic, and dependency management I'd encourage people (if they're running into this issue because of a * version pattern) to walk through the discovery and fix manually to start building up that knowledge.

It's great to have a copy/paste solution, but copy/paste without understanding what landed some people (including some members of my team) in this situation in the first place. That's why I tried to be super detailed in the why and how of the problem and fix.

Not trying to knock you down, just trying to caution people to address the real underlying problem.

[khromov]

@johnpbloch Really bad move to make this change without notice and break tens of thousands of Composer setups.

You should have created a new package instead and left this as legacy, or at least left the old branches intact so that dist links would keep on working.

[rask]

Confirmed while using

"require": {
    "johnpbloch/wordpress": "4.7.*"
}

Will attempt the cache and lock file juggling.

[ChrisWiegman]

Without any changes to composer.json I have everything running again this morning by removing vendor and the lock file, clearing composer cache and then running composer install again.

[andersryanc]

I think I'm experiencing a similar issue. In my case, I have the following in my composer.json:

    "johnpbloch/wordpress": "4.7.3",

This was working fine for a while, but I noticed after I added a new dependency and ran composer update that the hashes in the lock file changed for johnpbloch/wordpress:

            "source": { 
                "type": "git", 
                "url": "https://github.com/johnpbloch/wordpress.git", 
-               "reference": "eef7c0520b1e7187cd2cd7540dc997c4c3b0340a" 
+               "reference": "9f1f8eb6c37d10d73b9d7946c0ab5425a5492a9a" 
            }, 
            "dist": { 
                "type": "zip", 
-               "url": "https://api.github.com/repos/johnpbloch/wordpress/zipball/eef7c0520b1e7187cd2cd7540dc997c4c3b0340a", 
-               "reference": "eef7c0520b1e7187cd2cd7540dc997c4c3b0340a", 
+               "url": "https://api.github.com/repos/johnpbloch/wordpress/zipball/9f1f8eb6c37d10d73b9d7946c0ab5425a5492a9a", 
+               "reference": "9f1f8eb6c37d10d73b9d7946c0ab5425a5492a9a", 
                "shasum": "" 
            }, 

The GOOD reference is: eef7c0520b1e7187cd2cd7540dc997c4c3b0340a. Reverting those back manually seemed to fix it for me...

This just happened to me again today.

[rask]

This randomly keeps happening even with all caches cleared, locks destroyed, and vendor dirs cleaned.

I resorted to just adding the johnpblock/wordpress-core-installer and johnpbloch/wordpress-core directly to our composer.json. This may not be a wise choice in the long run but at least it seems to work better for now.

[aaemnnosttv]

To get past this error

[InvalidArgumentException]
Two packages cannot share the same directory!

Edit the vendor/composer/installed.json file, and remove the entry for the johnpbloch/wordpress package and save.

Run composer install.

[ghost]

I'm trying to automate my deployments [...]

@YarGnawh How's that going for you? I'm curious because like yourself I'm planning on working on the same thing and would appreciate any learnings you could share.

[ghost]

@johnpbloch Really bad move to make this change without notice and break tens of thousands of Composer setups.

@khromov you have the ability to fork and create your own composer module, or try another tool. Please do not shit on maintainers of FOSS tools. Because without them you wouldn't have had the pleasure of experiencing this issue.

[khromov]

@jhabdas Letting the maintainer know there were better options available is hardly to "shit" on them. If I woke up one day and decided to break a package for all its users, I'd expect some of them to voice their concerns.

[ghost]

@khromov I'm specifically referring to the following comment, where you shit on them:

Please don't do that. No cool. The FOSS community is a cornucopia of available options. And that being the case it's up to the individual consuming the software to read clause in the license which states NO WARRANTY and move on their their day. There's not much more to it.

[khromov]

@jhabdas The latter half of that comment was about possible ways to have avoided this scenario. I stand by that comment (very low-key criticism in my opinion) and I don't think I worded it in a harsh way. I also think it's silly @johnpbloch hasn't responded to this thread, although I don't blame him for it.

[johnpbloch]

@jhabdas please stop harassing @khromov. I never took his comment to be anything other than respectful and reasonable. And he was right.

@khromov it is a little silly. So let me start here:

I'm sorry. I made a pretty drastic change without thinking through all the implications. It broke a lot of sites and that's a pretty terrible result to have to own. You're absolutely right about both options for what would have been a better approach. Unfortunately, by the time you helped me see that, reverting the change would have re-broken all the sites that had just broken, so I just stayed the course. Again, I am sorry.

[ghost]

@jhabdas please stop harassing @khromov.

There's a clear difference between candor and harassment. @khromov and myself were having a conversation which didn't directly include you. But thank you for your misunderstanding.

[khromov]

@johnpbloch Thanks for the explanation. For what it's worth, I do think this change has improved the package structure a lot, so props to you! 🥇

[johnpbloch]

There's a clear difference between candor and harassment.

Category error. I can harass somebody candidly.

@khromov and myself were having a conversation which didn't directly include you.

It's strange to say that a conversation about me in an issue on one of my repositories is something I'm not included in or that I shouldn't be entitled to respond to.

But thank you for your misunderstanding.

You are the one who jumped down somebody's throat because you misunderstood something they said.

Please stay on topic or stop commenting. If you have something to add that is germane to the issue this thread is about, feel free to continue discussing that.