Hi !

I am trying to build a rock-solid profile based installation for a big client and I face an annoying issue.
I have to build two profiles. The first will be the core profile that all future drupal developments from this client will inherit, the second is a demo profile. Each of these profiles will be maintained by a different team.
Using the "base" attribute given by profiler in the demo profile, all the contrib dependencies from the core profile cannot be loaded because of their path.

I tried a workaround defining my own install tasks (highly inspired by Drupal core install tasks) allowing to choose a subprofile in my core profile but if this works well in D7.10, it does not work at all in D7.9. I attach you my profile install file and I hope you will have the time to find a way to patch this soon.

Regards.

CommentFileSizeAuthor
lp_core.install.txt7.53 KBduaelfr

Comments

q0rban’s picture

q0rban commented
Category: bug » support
Status: Active » Fixed

Hi there! I think I'm understanding. In order to use base profiles, you either need to keep. Ovules and themes in sites/all, or have duplicates in each profile's directory. Make sense?

q0rban’s picture

q0rban commented

Hi there! I think I'm understanding. In order to use base profiles, you either need to keep. Ovules and themes in sites/all, or have duplicates in each profile's directory. Make sense?

q0rban’s picture

q0rban commented

Hi there! I think I'm understanding. In order to use base profiles, you either need to keep modules and themes in sites/all, or have duplicates in each profile's directory. Make sense?

q0rban’s picture

q0rban commented

Oh dear. Sorry about that. Mobile-fail. Ovules == modules. :-)

duaelfr’s picture

duaelfr
he/him
Primary language French
Location Montpellier, France
commented

I am not talking about duplicate modules but dedicated ones.

What would you think of inserting base profile modules path in system table if they are not already in ? It should allow the core to find them during installation without disabling the ability to override them in sites/*/modules directories.

thsutton’s picture

thsutton commented

I was playing with this on the flight home from DDU2012 and ran into the same issue. I'd like to create a "CMS" profile and then another "Commerce" profile which extends CMS with additional details. I've managed to get it to work by:

1. Have an additional copy of the modules, libraries and themes in the "child" profiles; or

2. Put both profiles in the same directory and use a symlink for the "child" profile directory. (i.e. `cd profiles && ln -s parent_profile child_profile`).

3. I assume moving the modules, libraries and themes into `sites/all` would work too.

I think the current behaviour is wrong for two reasons:

1. Modules, etc. in one profile shouldn't be accessible to sites not using that profile (this rules out 2 and 3).

2. If we have to copy modules, themes, etc. from a base theme, we might as well copy everything else too.

Based on my past experience of forcing existing sites into a profile after the fact, I don't expect it'll be possible to make this work nicely (i.e. searching multiple directories for projects required by an install profile) but it would be nice to have.

duaelfr’s picture

duaelfr
he/him
Primary language French
Location Montpellier, France
commented

I agree with thsutton.

This subject is also discussed in Core Issues :

Mark F’s picture

Mark F commented

RE #4 - Not as bad as my mate who signed off his email to all of the managers "Retards, Alan" ;-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.