What's the best practice for where modules should be located inside an installation profile?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
dww's picture
sites/all/modules/*
35% (24 votes)
profiles/[profile_name]/modules/*
62% (43 votes)
Other (please comment with your proposal)
3% (2 votes)
Total votes: 69

Comments

Explanation and analysis

dww's picture

As pointed out by Eaton over at http://groups.drupal.org/node/7330#comment-21607 -- core supports finding modules in profiles/[profile_name/modules/*, in addition to /sites/all/modules/*, /sites/[site_name]/modules/* and /modules/*. We should have a best practice for where install profiles include their modules, regardless of if maintainers get to specify this in their .info/.pkg files or not. If it's hard-coded, we need to know what to hard-code. If it's flexible, we should have a recommended best practice for them to start from (and only deviate if there's a good reason).

To quote Jeff's original motivation for using the profiles directory:

The Drupal module system currently supports modules in the /profiles/foo/* directory as well as /modules and /sites/*/modules. Doesn't it seem like that's the logical location to hard-code things? If users copy a newer version of a module into sites/all/modules, it would override the profile-included copy, but wouldn't replace the overridden module on disk. That seems like the ideal solution...

For me, I'd never know to look in profiles/... to find the modules, so it seems potentially confusing to put them there. But, that's just me. ;) Comments welcome.

I really like Jeff's idea.

sime's picture

I really like Jeff's idea.

mental separation

mfer's picture

putting the modules in profiles/[profile_name]/modules/* has an added bonus of reminding us what modules came with the profile and what ones we added on later. I can see times arising where it could come in handy having this separation.

Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.mattfarina.com

There are a lot of times that this could be very useful.

mikey_p's picture

Keeping profile modules in /profiles/[profile_Name/modules/* is very important for one reason. Upgrade path.

It's the same reason we tell users to put their modules in site/all/modules.... so that they know which ones they need to copy out, and which ones will be included when the download a new tarball with Drupal 5.4 with SuperProfile 1.1.

Just make sure Drupal finds nested modules

mlncn's picture

In /profiles/[profile_name]/modules/

I'm assuming it does, so that og/contrib etc. will work.

It's already bugged me that you can't nest install profiles themselves ;-)

~ ben melançon

member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Web Development"

p.s. I think ASCII letter-art captchas are the coolest thing ever.

benjamin, agaric

I already use profiles/foo/modules

Crell's picture

We have a custom install profile for our "standard kit" at work, and we use profiles/palantir/modules for it. That helps us cleanly separate our standard modules from clean contrib (sites/all/modules) from custom coded (sites/default/modules). We don't yet use a common base theme, but when we do it will go in profiles/palantir/themes (in Drupal 6, where base themes work well finally).

Besides clear mental separation, It makes it easy for us to upgrade a site if a new release of a profile module comes out. We just re-export from svn our base install, and it overwrites the profile modules but not any that we've added specifically for that project.

So +1 to profile modules living ONLY in profiles/foo/modules (same for themes), and Drupal doing a full cascading search through, in this order:

/modules
/profiles/foo/modules
/sites/all/modules
/sites/foo/modules

Unsure on this one. One of

dragonwize's picture

Unsure on this one. One of the things I love about D5 is the sites directory and the ability to use the multi-site structure sites/[site_name]/...

If the modules are placed in profiles/[profile_name]/modules then we are taking away that great multi-site feature where you can control what modules are available for each site. We already have all the core modules that show up on every site whether used or not, now we add many more modules (as I can easily foresee profiles coming with a boat load of modules, this could get very messy).

We are also presuming that all sites in that install will be using the same profile. What if I have 5 sites with 5 different profiles all with 30 modules each. Firstly the modules admin would be totally unworkable. Secondly, how do we settle conflicts between 2 profiles that use the same contrib module, let's say Views, but one uses views 1.0 and the other uses views 2.0. Which views module gets shown on the module page? both? are they distinguished?

This brings up another point of will the profiled modules be separated on the module admin page like core modules?

I think a better solution would be sites/[site_name]/profiles/modules but am I don't know of any way to make that work with the packaging and release system.

OT: Usability improvements

sun's picture

This brings up another point of will the profiled modules be separated on the module admin page like core modules?

Now, that sounds interesting. The modules list in admin/build/modules always bugged me, specifically why we group core modules by "Core - required" and "Core - optional", and contrib modules (primarily) by usage. F.e., most evaluation/rating modules use the package string "Voting", but Poll module of core is in "Core - optional". And, of course, there are some more in "Other". Adding contrib modules to "Core - optional" would be insane, but moving (or duplicating) optional core modules to other groups is doable.

From a usability perspective I'd say that site admins search for modules providing certain functionality. Thus, the first group they'd search in would be "Voting", "Menu", "Administration", or whatever. So the two groups "Core - required" and "Core - optional" do not allow a wise and user-friendly categorization.

With install profiles, this will become even worse: What modules belong to the profile (without looking into the filesystem)? And which of them are required? Which meaning has "Core" in an install profile? Should they be grouped like "foo profile - optional" modules (NO!)?

EDIT: btw, there's already a great and simple module System mask that allows to require or hide certain modules in the modules list! (patch for 5.x)

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Not a good idea

mikey_p's picture

In all of my experience, and my testing, it seems that for any given site in a multisite or single site install, the profiles/[profile_name]/modules directory is not included if that profile is not enabled. It seems Drupal is already rather smart about this.

Secondly I'll reiterate that it is a bad idea to mix user modules with system and profiles modules. That's the only reason that sites/all exists, is to keep user modules out of /modules. The key thing here is UPGRADING. With profile modules scattered into places that aren't necessarily consistent such as /sites/[site_name]/profiles/modules this will make upgrading to a newer version of your distribution a nightmare.

In my brief stint attempting to maintain a profile here, I found the users consistently put downloaded modules everywhere but the place I told them to in the Readme.txt. I can only imagine the nightmare if you put profile/distribution modules anywhere in the /sites directory. I believe the intention of the /sites directory is to contain files that are not part of core, which is essentially what you are going to have to consider modules included with a distribution.

No

Boris Mann's picture

Works with multisite. You just have to install the site with the install profile, and it can grab it. Here's the over-ride stack -- sites/domain.com/modules trumps sites/all/modules trumps profiles/profilename/modules trumps modules

No Brainer

andremolnar's picture

/profiles/[profile name]/modules is the only place this make sense

/modules (is for core)
but can be clobbered by
/profiles/[profile name]/modules (is for profiles)
but can be clobbered by
/sites/all/modules (is a global override location)
but can be clobbered by
/sites/[foo.bar.example.com]/modules (is for site specific overrides)

andre

Distributions

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: