Try this on a new Drupal install:

  1. Go into the "profiles" directory.
  2. Create a "foo" directory.
  3. Move the "minimal" profile directory into the "foo" directory.
  4. Go to install.php. On the profile selection screen, the Standard profile will display as normal, but the Minimal one will display as just "minimal" (so not the proper profile name) and with no description.
  5. Select "minimal" and then select a language. The next screen will grimly tell you "Sorry, the profile you have chosen cannot be loaded."

So the problem is that the code which finds profiles is finding profiles that the code that loads the profiles can't load. Since I think it's useful to be able to have profiles in subdirectories (so you could have, say, a "commerce" install profile project which is actually a directory with "commerce_light" and "commerce_standard" subdirectories which are functional profiles), and we already allow modules and themes to be in subdirectories, I'm going to fix the latter.

If for some reason we don't want to allow install profiles to be in subdirectories, then we need to go the other way and fix it so they don't show up on the profile selection page.

EDIT: I marked as a "feature request," but could also be labeled as a bug; either "Install profiles in subdirectories don't work" or "Install profiles in subdirectories shouldn't show up on the select form." (Especially if labeling it a bug will allow it to get into D7 easier. :P )

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Garrett Albright’s picture

Whoops, let's not break supporting .po files in profile directories.

David_Rothstein’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7

This is basically the same issue as #1016392: Installation profiles fail when in subdirectories - easy fix. Not sure if we should close one as a duplicate, or keep that as a bug report and this as a feature request.

For Drupal 7, the simplest and least intrusive way to fix the bug is to remove these from the profile page (rather than adding a new feature which allows them to live in a subdirectory). In the other issue, my thought was that fixing this by adding the new feature would not be acceptable for a stable release. On the other hand, I guess the amount of non-core code out there that relies on finding all profiles in the top level of the directory is probably not huge...

For Drupal 8, it totally makes sense to allow them to be in subdirectories, though.

Garrett Albright’s picture

Here's a D8 patch. It's an improvement over the D7 one because it finds more places where "/profiles/$profile" and such were hard-coded.

I totally want to see this in D7. It will make a possible upcoming project much easier to deal with. And it makes sense, doesn't it? If we allow modules to be in subdirectories, and profiles are just specialized modules…

sbandyopadhyay’s picture

I absolutely agree with Garrett, it makes sense to have it in D7 -- and D6 too. My patch in #1016392: Installation profiles fail when in subdirectories - easy fix, which I'm marking as a duplicate of this issue, has been working fine for me for nearly a year now. I'd love to see it in D6, after it's first fixed in D7 and D8 perhaps.

There's no reason to handicap D6 and D7 by preventing subdirectoried install profiles rather than improve D6 and D7 by expanding that capability -- especially when the fix is quite simple.

jrreid’s picture

Heres a re-roll of the patch in #3 against the latest 8.x

The last submitted patch, allow_profiles_in_subdirs-1393442-4.patch, failed testing.

jrreid’s picture

Status: Needs work » Needs review
jrreid’s picture

Issue summary: View changes

Add note about how this is both a feature request and a bug

Garrett Albright’s picture

Version: 8.x-dev » 7.x-dev
Issue tags: -Needs backport to D7

This appears to longer be an issue for Drupal 8. I was just able to do installs with core/profiles/foo/standard and profiles/foo/standard just fine.

The patch in #3 still applies for Drupal 7 and still works correctly.