Branched from #295434: Support contrib being placed in profiles/all.

Problem: a single Drupal distribution cannot easily contain more than one install profile. Such a distribution would need to duplicate each module or theme into each profile. That's silly.

Also, install profiles cannot share other resources readily, like a common include file for install functions.

A couple possible suggestions:

yhahn - September 23, 2010 - 11:26

I would add to #33 that a better solution to the use case at hand - having a distribution ship with multiple install profiles that are managed together and expect the same dependencies / module versions - would be to better distinguish between an install profile's search path and the install profile's install/update routines.

For example, if there were such a distinction a set of profiles (I will call them apples, bananas and oranges) that share the same search path might look like this:

profiles/fruits/fruits.make
profiles/fruits/apples.install
profiles/fruits/apples.info
profiles/fruits/bananas.install
profiles/fruits/bananas.info
profiles/fruits/oranges.install
profiles/fruits/oranges.info

Much like how a single Drupal.org project can contain multiple modules, this would allow a profile project to contain different "variant" install profiles though they all share and have jurisdiction to using the projects found in profiles/fruits.

The main change required for this would be to eliminate the convention/assumption that the active install profile is both the search path directory and the filename of the info/install files within that directory. To this end see adrian's work on #911354: Tests in profiles/[name]/modules cannot be run and cannot use a different profile for running tests.

an alternative suggestion would be supporting the sharing of modules within a group of profiles like:

/profiles/[group-name]/[profile-name#1]/modules

/profiles/[group-name]/[profile-name#2]/modules

/profiles/[group-name]/all/modules

so either profile #1 or #2 could use the "all" modules for the group.

It's likely that any such change could go into Drupal 7 (And even Drupal 6) as long as the existing naming system continues to work.

Comments

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

Once there is a consensus on how we want to achieve this, I think we should (maybe not in this issue, though) think about whether such a grouping makes sense on the sites-level as well, i.e. to group related sites. Going with the latter approach in the op, the analogy would be:
/sites/blogs/all
/sites/blogs/example1.com
/sites/blogs/example2.com
/sites/community/all
/sites/community/example3.com
...

dww’s picture

dww
we/he/they
commented

Interesting stuff. There will probably be implications for the d.o distro packaging system as a result of this, so I'm keen to see how this evolves. That said, please don't let d.o packaging considerations/limitations influence this discussion. We should just come up with something slick that solves all our problems, get core to support it, and then we can make d.o package the distros accordingly. I'm totally on board to help.

In short: please don't comment in this thread with something like "but the d.o distro packaging doesn't support X so we should do Y". ;)

Thanks,
-Derek

pwolanin’s picture

pwolanin commented

@tstoeckler - in drupal 7 you can already do that for multisite using the sites.php functionality, so I don't think we should add anything more to core regarding it.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

I'm aware of sites.php, but I'm not sure how you'd do multiple .../all folders with that. Anyway, I think the 'sites' problem is for another issue, or at least we should figure out the 'profiles' problem first.

adrian’s picture

adrian commented

This patch hopes to make the search paths configurable, and eventually add the ability to add additional directories from settings.php and sites.php

http://drupal.org/node/911354#comment-3481270

sites.php on it's own does not do additional search paths currently.

This issue will require us to change code such as the following, by storing the profile path during install : 

  // Allow the installation profile to modify the full list of tasks.
  if (!empty($install_state['parameters']['profile'])) {
    $profile_file = DRUPAL_ROOT . '/profiles/' . $install_state['parameters']['profile'] . '/' . $install_state['parameters']['profile'] . '.profile';

We will also need to modify the system_listing search path to use drupal_get_path instead :

     $searchdir[] = "profiles/$profile/$directory";

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.