Cannot find profiles beneath top-level directories

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".

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.

Moving to proper queue.

Through Drupal 7 (at least) profiles can't be placed in subdirectories: https://api.drupal.org/api/drupal/includes%21install.core.inc/function/i....

I think the original report has more to do with how a site import determines the proper profile. In http://api.aegirproject.org/api/Provision/platform%21drupal%21import_7.i..., we default to 'standard' is the 'install_profile' variable isn't set. Perhaps that was causing this issue?

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?

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/install.core.inc:

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

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
https://github.com/drupal-composer/drupal-project
and
https://github.com/acquia/lightning-project

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 https://github.com/drupal-composer/drupal-project/blob/8.x/composer.json... )

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

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

Hello,

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.

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 packages_6.inc and packages_7.inc, and stripping out the D8-specific stuff. Similary, move it to packages_8.inc stripping out the legacy stuff. Then we can start re-factoring the D8 code more aggressively.

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

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.

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.

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

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)

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

Merged