The docs are out of date still referencing drush dl.

https://www.drupal.org/docs/8/multisite/drupal-8-multisite-on-a-lamp-stack

how do i install multisite subdomain modules locally using composer?

Do multisite submdomains require their own local composer.json in addition to their own settings.php?

What is the recommended practice for installing modules, libraries and themes beyond drush dl?

thanks

Comments

laurencefass created an issue. See original summary.

Syntapse’s picture

Issue summary: View changes
Syntapse’s picture

Issue summary: View changes
Syntapse’s picture

Title: how do i composer require multisite sub domains? » how do i composer require multisite sub domain modules, themes and resources?
Issue summary: View changes
cilefen’s picture

AFAIK that's not a solved problem.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

wolf_22’s picture

So 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.

cilefen’s picture

Yes.

This should probably be closed as a duplicate of #3004496: Document best practices for multisite and composer.

mmjvb’s picture

No, 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

wolf_22’s picture

Then 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)?

cilefen’s picture

Status: Active » Closed (duplicate)

There is none.

Let's close this now because the technical specifics are being hashed out in #3004496: Document best practices for multisite and composer.

mmjvb’s picture

composer/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.

wolf_22’s picture

Status: Closed (duplicate) » Active

But 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.)

mmjvb’s picture

Status: Active » Closed (duplicate)

That is the one!

wolf_22’s picture

(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:

"installer-paths": {
    "../public_html/mydrupalfolder/core": [
	"type:drupal-core"
    ],
    "../public_html/mydrupalfolder/libraries/{$name}": [
	"type:drupal-library"
    ],
    "../public_html/mydrupalfolder/sites/site1.com/modules/contrib/{$name}": [
	"drupal/address"
    ],
    "../public_html/mydrupalfolder/modules/contrib/{$name}": [
	"type:drupal-module"
    ],
    "../public_html/mydrupalfolder/profiles/contrib/{$name}": [
	"type:drupal-profile"
    ],
    "../public_html/mydrupalfolder/themes/contrib/{$name}": [
	"type:drupal-theme"
    ],
    "drush/Commands/contrib/{$name}": [
	"type:drupal-drush"
    ],
    "../public_html/mydrupalfolder/modules/custom/{$name}": [
	"type:drupal-custom-module"
    ],
    "../public_html/mydrupalfolder/themes/custom/{$name}": [
	"type:drupal-custom-theme"
    ]
},

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.

cilefen’s picture

But what if you wanted address also in another sub-site? It won't work.

wolf_22’s picture

cilefen, 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:

[Seld\JsonLint\ParsingException]
"./composer.json" does not contain valid JSON
Parse error on line 56:
...ntrib/{$name}": [ drupal/address
---------------------^
Expected one of: 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '[', ']'

(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...

mmjvb’s picture

See 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.

jshimota01’s picture

Not 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