Closed arvilmena closed 5 years ago
Hi @arvilmena,
Thanks for asking your question. The issue at root here is a conflict between how Composer works and the default way WordPress works.
If you want to use Composer to manage WordPress core as a dependent package, you have to use a specific non-standard installation option for WordPress in which core is installed in a subdirectory and the wp-content directory is set to a location outside of the core package. @Rarst has a great microsite detailing the optimal setup. You can also check out my sample WordPress package starter package for inspiration. You can read more about installing core in a subdirectory and moving wp-content on the codex.
If you're interested in reading a little more about the reasoning for this issue, please see this thread in the installer repository in which the topic gets a bit more lengthy treatment.
Hope that helps!
@arvilmena it just occurred to me that your question was slightly different than I had understood. You're familiar with the "standard" way to run a wp/composer stack, but you wanted to know if there's a way to use composer to manage dependencies inside a normal wp stack.
Short answer: no, not with this package.
Long answer: Basically, that install structure is not supported by Composer itself. Now, it's possible you might be able to write a plugin package that hooks into pre-install/update/delete events and uses wp cli to download, update, and install/update wordpress core into the correct directory while allowing a dummy package to get installed into vendor. Before I made this package I was playing around with a Composer plugin that dynamically added package definitions for WordPress core into an in-memory repository for Composer to use, but that proved to be too brittle at the time. You may be able to get it to work now. I'm not sure. But that's not something I'm interested in doing with this package.
https://github.com/johnpbloch/wordpress-core-shim This is the plugin package I'd built. Like it says in the readme, I only ever got it working using global installation, and it was pretty brittle. Hopefully it can provide some inspiration if you decide to make a composer plugin to make standard stacks work correctly. I think it's a pretty exciting idea! 😄
For git managed custom folders, a workaround is adding post install script that undo the deletion.
In composer.json
"scripts": {
"post-install-cmd": [ "chmod +x ./reset-deletion.sh && ./reset-deletion.sh" ]
}
In reset-deletion.sh
#!/bin/bash
git checkout public/wp-content/
Say in your composer.json, you have the following packages:
Say in your
composer.json
, you have the following packages:The
composer.json
above says you required 3 plugins: better-search-replace, bugherd, and disable-emojisBut when you hit
composer install
:You'll only get 1 plugin inside
wp-content/plugins
folder. The reason for this is because when you check the print above, the 2 pluginsbetter-search-replace
andbugherd
where installed first BEFORE the Wordpress core filesjohnpbloch/wordpress
. So evencomposer
extracted those 2 plugin packages to its correct folder, thejohnpbloch/wordpress
has removed them because it overwrote thewp-content/plugins
folder.The only way for this to work is if I install
johnpbloch/wordpress
first before the plugins, but I do not know if its possible since composer install via thecomposer.lock
content.Hopefully there's an option to disable wordpress-core to overwrite/remove existing files?
P.S. I only opened this issue as it was recommended in StackOverflow
Regards,