Comments (26)
@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.
from wordpress-core-installer.
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
from wordpress-core-installer.
@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.
from wordpress-core-installer.
@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.
from wordpress-core-installer.
@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! 🥇
from wordpress-core-installer.
Confirmed while using
"require": {
"johnpbloch/wordpress": "4.7.*"
}
Will attempt the cache and lock file juggling.
from wordpress-core-installer.
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.
from wordpress-core-installer.
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.
from wordpress-core-installer.
I am getting the same issue as well!
from wordpress-core-installer.
Ugh, can confirm this issue.
from wordpress-core-installer.
Looks like now you have to use johnpbloch/wordpress-core
package instead of johnpbloch/wordpress
from wordpress-core-installer.
@BoShurik I tried both, there is no diff. Removing the composer.lock file works
from wordpress-core-installer.
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
from wordpress-core-installer.
@ocean90 thanks! removing and adding it works. though it's far from ideal 😐
from wordpress-core-installer.
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?
from wordpress-core-installer.
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
from wordpress-core-installer.
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.
from wordpress-core-installer.
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.
from wordpress-core-installer.
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.
from wordpress-core-installer.
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.
from wordpress-core-installer.
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
.
from wordpress-core-installer.
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.
from wordpress-core-installer.
@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.
from wordpress-core-installer.
@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.
from wordpress-core-installer.
@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.
from wordpress-core-installer.
@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.
from wordpress-core-installer.
Related Issues (20)
- Improve exception message HOT 2
- Please consider adjusting license to ISC/MIT HOT 3
- Apply GPL License Header
- Only install if directory doesn't exist or is empty HOT 2
- plugins and themes HOT 10
- wp-config.php HOT 3
- [question] when the execution of the script is indicated? HOT 2
- Permissions are 777 for every single file and directory installed by this package HOT 1
- Use WP.org repo ZIP-s HOT 4
- Continued to use ^1.0 as your version constraint no longer possible HOT 1
- WordPress files get removed with Composer v2 HOT 3
- folder issue if wp-content created by wpackagist in the same time HOT 4
- Prevent installing default themes/plugins
- New plugin system in Composer HOT 1
- Conflict with Composer/Installers? HOT 5
- wordpress-core-installer broken since last commit HOT 10
- Installer removes all contents with update HOT 4
- Admin not working after server change HOT 1
- Setting `"wordpress-install-dir": "."` erases installation directory HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wordpress-core-installer.