Modules directory best practice

[paul121]

From our module development documentation: https://farmos.org/development/module/#modules-directory

Modules should be placed in the sites/all/modules directory of the server's document root. If you are using the farmOS Docker image, this will be: /var/opt/drupal/web/sites/all/modules

A good practice is to download farmOS-specific modules into modules/farm to keep them separate. You may also consider creating a modules/custom directory for custom modules that are specific to your farmOS instance.

But this composer-project places all drupal-module composer dependencies into web/modules:

composer-project/composer.json

Line 29 in eb17507

"web/modules/{$name}": ["type:drupal-module"],

Is there an easy way to distinguish farmOS modules and update this composer project to place them into sites/all/modules/farm instead?

It seems that web/sites/all/modules is a convention from Drupal 6/7, and web/modules is new with Drupal 8. From https://www.drupal.org/docs/creating-custom-modules/naming-and-placing-your-drupal-module:

Previous Drupal versions demanded custom modules to be located in /sites/all/modules as the core modules were located in /modules. However, in Drupal 8 /modules is now freed up for your custom and contributed modules. All core modules and libraries files are now located in the /core directory. In Drupal 8, you can still use the Drupal 7/6 best practice of putting your custom and Drupal.org contributed (downloaded) modules into /sites/all/modules but you can also just put them into the /modules directory, which has the same effect.

Given this, I'm curious if we should update our documentation/best practice to place modules into web/modules instead (in which case this issue may be in the wrong repo 😄 ). It seems like this requires less configuration and is more aligned with current drupal practices.

[mstenta]

Good questions @paul121... and somewhat relevant comment here worth linking in: #3 (comment)

It's a bit tricky...

But this composer-project places all drupal-module composer dependencies into web/modules:

This is only the case for modules pulled in via Composer. Not everyone uses a Composer-based approach to installing/hosting farmOS. And in those cases (assuming they are using Docker), is to bind-mount the sites directory as a volume, and put all the stuff they want to persist in there (including settings.php, uploaded files, and manually downloaded modules.

I think that's still the best approach for non-Composer-based installations. You can't really bind-mount the root modules directory in that case, because that will result in the directory being EMPTY when the container starts.

However, I recently stumbled upon a pretty nasty core issue with using sites/[uri]/modules (although I'm not sure if that also applies to sites/all/modules - haven't tested): https://www.drupal.org/project/drupal/issues/2985199

In either case, maybe we need to make it more clear in our docs what the different considerations are, depending on how you are hosting/installing farmOS. Or maybe we just need to finally add some "officially supported" documentation for Composer-based installs.

[paul121]

Hmm yeah that is tricky.. not using a composer-based approach seems like it will cause headaches down the road... but alas...

Or maybe we just need to finally add some "officially supported" documentation for Composer-based installs.

Yeah, I guess this would be the best solution then. To a certain degree I feel that the documentation is incorrect/mis-leading for anyone using composer.

[mstenta]

not using a composer-based approach seems like it will cause headaches down the road... but alas...

Depends on the use-case. For advanced deployments, where you are maintaining multiple contrib modules, and custom modules, Composer makes the most sense. But that's not going to be most of the audience. We need to be able to support the simple "drop in this container and point it at this directory for persistence" workflow. The only headache I foresee there is that Drupal core issue I linked to... but ideally that will be fixed upstream.

To a certain degree I feel that the documentation is incorrect/mis-leading for anyone using composer.

It is, I agree - because we don't "officially" support Composer-based workflows (yet). :-)

I would love to though... someone else asked about this in the chat today, and I suggested we start a forum topic to discuss best practices.

[mstenta]

Closing this because we have Composer documentation now: https://farmos.org/hosting/composer/