Starting in Drupal 8, installation profiles can live under subdirectories under profiles/. These might commonly be profiles/contrib or profiles/custom. Provision doesn't currently recurse into subdirs when searching for profiles, and so these are missed.

A good example of a platform that does this is Thunder.

Original bug report by SocialNicheGuru:

I am not sure if this is only my install
I import a platform
The sites were imported
I imported the databases
But the only profile in the profiles directory that can be read is standard
I have openatrium in the profiles directory with 'chmod -R 777 openatrium' and the system does not read the folder at all.

Members fund testing for the Drupal project. Drupal Association Learn more


SocialNicheGuru created an issue. See original summary.

SocialNicheGuru’s picture

Title: Import of platform with sites only use a standard profile » Import of platform with sites only uses the standard profile. other profiles not seen by system
helmo’s picture

So if you go to the 'Packages' tab of your platform and select type=installation profile, you do not see openatrium?

I just tried... added openatrium to an existing platform, ran verify, and it was found.

The log of your platform's verify task might contain clues ... it reports on the number of found modules. Search for "Found install profile standard".

colan’s picture

Title: Import of platform with sites only uses the standard profile. other profiles not seen by system » Cannot find profiles beneath top-level directories

In my case, I had a profile in /profiles/custom/, not simply at /profiles. It seems like the code in _provision_find_profiles() is only looking at the top level. So I'm guessing that's the problem found above.

This function needs to be rewritten to account for the convention of putting profiles in contrib and custom subdirectories, just like the convention for doing this with modules/.

We should probably be using file_scan_directory() here instead.

colan’s picture

Project: Hostmaster (Aegir) » Provision

Moving to proper queue.

ergonlogic’s picture

Through Drupal 7 (at least) profiles can't be placed in subdirectories:

I think the original report has more to do with how a site import determines the proper profile. In, we default to 'standard' is the 'install_profile' variable isn't set. Perhaps that was causing this issue?

colan’s picture

Through Drupal 7 (at least) profiles can't be placed in subdirectories

I'm not sure about 7, but I have /profiles/custom/... working fine in Drupal 8 outside of Aegir. Want me to open a new issue for this so we can set this one back?

ergonlogic’s picture

We should probably try to untangle that code, and move _provision_find_profiles() to the version-specific engines.

In D8, this is done on line 420 of core/includes/

  // Add list of all available profiles to the installation state.
  $listing = new ExtensionDiscovery($container->get('app.root'));
  $install_state['profiles'] += $listing->scan('profile');
dman’s picture

Thanks for the explanation as to why this is in #6 ergonlogic
It's slightly new behaviour, yes, but the assumption it would would work also makes sense.

This is hitting us, as we start building things with

The composer-based build, for consistency(?) reasons, wants to place the things of type 'drupal-project' into the folder 'profiles/contrib' by default

(Tweaking our composer.json to not do that provides a work-around )

Is already there an issue here in provision that's already allowing recursive searches within the /profiles dir?

memtkmcc’s picture

@dman For drupal-composer specific issue, check #2736801: Support Composer for platform builds

Grimreaper’s picture

Status: Active » Needs review
8.24 KB


Here is a patch that add the custom and contrib sub dir. I refactored the detection function to have 'required' and 'optional' profiles directories.

Thanks for the review.

ergonlogic’s picture

Thanks for the patch, @Grimreaper.

I'm not sure this is the right approach, since we'd be hard-coding contrib and custom in this case.

For example, in _provision_drupal_find_modules() we use drush_scan_directory() to recursively scan for files ending in .module . I think we could do something similar for profiles. This is a little more complicated in D8, since we no longer require a .profile (see the minimal and testing profiles.) However, profiles' .info.yml will contain: type: profile.

I think the best bet here is to begin by moving _provision_find_profiles() into and, and stripping out the D8-specific stuff. Similary, move it to stripping out the legacy stuff. Then we can start re-factoring the D8 code more aggressively.

ergonlogic’s picture

Issue summary: View changes

Updated the issue description, since we'd hijacked it pretty thoroughly.

ergonlogic’s picture

Status: Needs review » Needs work

I've begun refactoring as I described above in the dev/2650290 branch. While profiles in subdirectories are now found, packages within those profiles are not.

ergonlogic’s picture

Similarly, themes in profiles under subdirectories are also skipped. It looks like _provision_drupal_search_paths() (and maybe also _provision_find_packages() and _provision_drupal_find_modules()) should get similar treatment. That is, split out into the version-specific package includes, and re-factored from there.

ergonlogic’s picture

Status: Needs work » Needs review
13.13 KB

Here's a consolidated patch of the various commits I've made to the dev/2650290 branch.

helmo’s picture

Seems to be working OK, I have it on my feature/quick-review branch now.

Let's try to get this in before #2841435: [meta] 3.10 release (bugfix/patches)

colan’s picture

Code looks good, but haven't had a chance to try it.

helmo’s picture

Status: Needs review » Fixed


  • ergonlogic authored 1cda2be on 7.x-3.x
    Issue #2650290: Search for packages in D8 profiles under subdirs.
  • ergonlogic authored 2628e63 on 7.x-3.x
    Issue #2650290: Scan for Drupal 8 profiles in subdirectories.
  • helmo committed 9f2b6a5 on 7.x-3.x
    Issue #2650290: Search for packages in D8 profiles under subdirs. (Merge...

Status: Fixed » Closed (fixed)

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