Documentation I have read (such as https://www.drupal.org/node/2718229) says the JSON file should be configured like this:

"installer-paths": {
            "core": ["type:drupal-core"],
            "libraries/{$name}": ["type:drupal-library"],
            "modules/contrib/{$name}": ["type:drupal-module"],
            "profiles/contrib/{$name}": ["type:drupal-profile"],
            "themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"],
            "modules/custom/{$name}": ["type:drupal-custom-module"],
            "themes/custom/{$name}": ["type:drupal-custom-theme"]
        }

Yet on my currently working site (pre-Composer) where themes and modules were installed using the Administration panel, there are no contrib or custom subfolders. Modules were installed (by their name) in the modules folder, and not the modules/contrib folder. Likewise for the others.

Where is really the correct area to install modules, both on a website that has a fresh Drupal install and a website where things had already been installed with the Administration panels? Or is Composer very flexible, and it handles whatever the programmer wants (and specifies)?

Comments

sprite’s picture

Inside Drupal, when using the admin GUI to enable modules, its "discovery" code is able to find modules in multiple locations, which is why the folder placement differences don't really matter. Back in the D7 days, people often just placed their modules in /sites/all/modules/ using a scheme of their choosing. For example, to this day, in D7 I put all commerce modules in /sites/all/modules/commerce/ to distinguish them from other modules. I'm pretty sure it remains possible to even place module code in the old /sites/all/modules location and Drupal 8 will still find it.

Keep in mind also, that the composer utility is not really directly aware of Drupal, it is just installing code "packages", from a universe of PHP and javascript code stored in various web locations (mostly github - the version management empire that currently rules the dev galaxy), and managing their dependencies, making sure all dependent code is properly versioned. Drupal isn't currently directly aware of the composer utility either (that is a matter/problem for its own discussion scope elsewhere).

Keep in mind also, that a composer.json file will work without an "installer-paths" section in it all. I'm running composer.json files without that section and composer is using defaults on its own.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

Reg’s picture

The convenience of separating out custom and contrib modules is really for module developers. It can be a little annoying having to look through 100+ modules to figure out which ones where custom for a particular website vs. which ones are stock standard on drupal.org - even if you are the developer who let it get that way!

If you don't have a developer who's going to make custom modules for you, I say it doesn't matter, let Drupal do it's default thing.

Also, Drupal 8 opens up a new possibility in that if it places all the modules under /modules just for convenience a developer could simply place all custom modules under /sites/all/modules or /sites/all/modules/custom and the custom modules would be separated out from contrib modules anyway - even though with /sites/all/modules you don't get the explicit statement that you are looking at custom modules, it's will be easy enough for a competent Drupal developer to figure that out.

Personally, since I am a module developer, I'll change composer's defaults so it installs modules under /modules/contrib but that's purely for my own convenience and would not consider it useful advice for anyone else without knowing that the circumstances warranted it.