Closed (duplicate)
Project:
Drupal core
Version:
9.1.x-dev
Component:
composer
Priority:
Major
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
13 Nov 2018 at 13:09 UTC
Updated:
13 Jun 2020 at 16:47 UTC
Jump to comment: Most recent
Comments
Comment #2
Syntapse commentedComment #3
Syntapse commentedComment #4
Syntapse commentedComment #5
cilefen commentedAFAIK that's not a solved problem.
Comment #9
wolf_22 commentedSo are we saying then that there's absolutely no way to install a module to a specific sub-site within a multisite Drupal installation if said module is Composer-managed? Because I've been planning on using the sub-site functionality to accommodate multi-environment sites using 1 codebase but if the above stipulation is true, it would mean I'd have to install, say, "Address" into the /sites/all folder instead of something like /sites/site1/modules folder.
Comment #10
cilefen commentedYes.
This should probably be closed as a duplicate of #3004496: Document best practices for multisite and composer.
Comment #11
mmjvb commentedNo, that is absolutely not what is being said!
With a composer managed code base you use composer/installers to get the code at the destination you want. Unfortunately there is no command available still for deciding on the destination. That means you need to specify that up front.
Do remember that a limitation of composer is to only have a package available once, regardless where you place it. So, as long as there are no overlapping modules you can do with one specification (composer.json)
Obviously, nothing stops you from combining composer method with manual. Only becomes difficult with diverging dependencies. Makes you wonder whether they should be in the same multisite
Comment #12
wolf_22 commentedThen how would you install something like "Address" into, say, "/sites/site1.com/modules/contrib" using your approach with vanilla Composer and a fresh download of Drupal (which was downloaded with Composer)?
Comment #13
cilefen commentedThere is none.
Let's close this now because the technical specifics are being hashed out in #3004496: Document best practices for multisite and composer.
Comment #14
mmjvb commentedcomposer/installers allows you determine the destination. The format is path:package
In your case path would be: /sites/site1.com/modules/contrib/{$name}
package would be: drupal/address
Not sure, but sounds poor organization to me. Referring to `contrib`, suggest more proper thinking about organizing extensions.
Comment #15
wolf_22 commentedBut what is this "composer/installers" you're referring to? Is that some sort of Composer add-on / module or is that an inherent command for vanilla Composer? (I've never heard of it.) I took to Google to search for information about it and I found a repo about a "multi-framework Composer library"--is this what you're talking about?
(Sorry--didn't mean to reopen this. I'd close again if I could. I didn't realize commenting on something reopened it.)
Comment #16
mmjvb commentedThat is the one!
Comment #17
wolf_22 commented(For anyone that comes across this...)
Based on what mmjvb mentioned above, I was able to accomplish custom install paths of specific modules within a Composer-managed project using the following steps:
1.) Look in your composer.json file to verify you have "composer/installers" as a line-item inside the require section... If you do, move on to step 2 below. If not, I'd assume it could be added by adding the specific version you need or want (whatever the latest is?) whereby you would then issue a "composer update" to download everything. (Correct me if I'm wrong about that and do that at your own risk.) Personally, I don't think this should happen to you but if it does, it might be an issue with your project worth looking into.
2.) Underneath the extra section, you should see an installer-paths sub-section which defines the paths associated to your Drupal project. To define a custom path for a specific module (i.e. - if you want to install a specific module into sites/site1.com/modules/contrib for a multisite setup), you would add something along the following lines to your installer-paths section:
Very important: the Address install path above absolutely has come before the default drupal-module install path entry underneath it. Failure to do that results in Address being installed into the default /modules/contrib location. But once your custom install path entry has been added to your composer.json file, save it.
3.) Finally, issue "composer update". You should see the one-off module (or modules, depending on how extensive or customized your project is) being installed into their respective paths whereby if you later issue a standard "composer require" for some other module, it should be installed to the default location like normal--these customizations only happen for those you explicitly dictate in your custom install paths, leaving all others to install like normal into the default path. Just remember to put the custom entries before the default entry.
After testing all this, it appeared to work as expected for me. :.)
Thanks for the insights, mmjvb. If any of that is wrong, feel free to correct it.
Comment #18
cilefen commentedBut what if you wanted address also in another sub-site? It won't work.
Comment #19
wolf_22 commentedcilefen, I wish I could say you're wrong but you're not. Just confirmed it. Sigh... The level of disappointment this brings me can't be described using words. Anyway, it breaks at build time with the following being printed in the CMD window:
(Happened after adding Address to an additional sub-site install path entry underneath the installer-paths section and trying to run "composer update".)
Thanks for chiming in. I guess for me, everything is going into /sites/all for the time being...
Comment #20
mmjvb commentedSee no reason for it not to work. Its dependencies are generally available. So, manually copy to other sites would make it available there. Or use symbolic links. You may even do that as a standard. Put those modules in a dedicated place and make them available using symbolic links.
Comment #21
jshimota01 commentedNot sure this is the right place - so starting here - I thought I had gotten my environment under control but recently something has changed and now I'm broken.
I run a WAMP64 dev env. - multiple PHP versions and multiple websites. I have 8 different client sites with both d7 and d8 cores.
With the advent of the composer D8 websites - Drush is broken.
On the site I initially started, drush works. If I open a command window and move to the docroot of that site (ie: cd c:\wamp64\www\ubp)
then issue Drush Status - it looks fine.
Then I change to 'c:\wamp64\www\ubp-d8-sgfull' and issue 'drush status' and it blows up with:
Fatal error: Uncaught TypeError: Argument 2 passed to Symfony\Component\EventDispatcher\EventDispatcher::dispatch() must be an instance of Symfony\Component\EventDispatcher\Event or null, string given, called in C:\Users\JShimota.E-WIZ\AppData\Roaming\Composer\vendor\consolidation\annotated-command\src\Hooks\Dispatchers\CommandEventHookDispatcher.php on line 30 and defined in C:\wamp64\www\ubp-d8-sgfull\vendor\symfony\event-dispatcher\EventDispatcher.php:37
Stack trace:
#0 C:\Users\JShimota.E-WIZ\AppData\Roaming\Composer\vendor\consolidation\annotated-command\src\Hooks\Dispatchers\CommandEventHookDispatcher.php(30): Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object(Symfony\Component\Console\Event\ConsoleCommandEvent), 'console.command')
#1 C:\Users\JShimota.E-WIZ\AppData\Roaming\Composer\vendor\consolidation\annotated-command\src\Hooks\HookManager.php(424): Consolidation\AnnotatedCommand\Hooks\Dispatchers\CommandEventHookDispatcher->callCommandEventHooks(Object(Symfony\Component\Console\Event\ConsoleComma in C:\wamp64\www\ubp-d8-sgfull\vendor\symfony\event-dispatcher\EventDispatcher.php on line 37
To complicate matters, the working site is a multisite - I've overcome the complexity of that for the but it does add to my confusion.
Anyone with thoughts? Care to direct me somewhere else?
Thanks. Shu