Allow install profiles to be switched

+1 on this, I have been bitten when upgrading from a Drupal 6 site that was originally created with a custom install profile that does not and will not exist in Drupal 7. There is no way to upgrade without errors if the system has a value in the install profile name variable and there is no way to uninstall the install profile other than to manually alter the variable.

I will also note that many of the people reporting these errors originally created sites using the Acquia distribution, so there are quite a few of them. In some cases they were just using the distribution as an easy way to get started and had no intention of being permanently tied to it. In some cases they don't even realize they are tied to it ("I *think* I might have used the Acquia installation").

If already in profiles->modules utopia: can one possibly install several profiles in same time? What are the ux/support consenquences?

I'm increasingly of the opinion that there is a significant design flaw embedded in the current concept of "installation profiles."

"Installation" is something that happens once, and only once, when a website is first created. I think it is inherently problematic, therefore, to use installation profiles to both perform initial setup and to provide site configuration after the initial setup has been completed.

Every website that I have ever worked on has required customization after the initial setup. I think it is actually rare and unusual for an installation profile to be able to anticipate all of the ways that a website's owners will want to customize and modify the site after the initial configuration has been completed. Why, then, should installation profiles continue to enforce things like module dependencies? At present, I find myself forced more often than not to hack the code of an installation profile post-installation simply so I can turn off a feature that I don't want.

If I set up a website using the Acquia Commons module, for example, it enables the admin module. However, suppose I prefer to use the admin_menu module instead (which, in fact, I do). Why should I have to edit the installation profile simply so I can make this change?

There are, of course, situations where there are good reasons to want to bundle together configuration settings, but Drupal offers other mechanisms, such as the Features module, for doing so.

If I set up a website using the Acquia Commons module, for example, it enables the admin module. However, suppose I prefer to use the admin_menu module instead (which, in fact, I do). Why should I have to edit the installation profile simply so I can make this change?

Why would you have to edit the installation profile? You can just turn off the module via the user interface.

That said, hiding modules or preventing them from being disabled is certainly something installation profiles can do if they want to (especially in D7), and it's an important feature since it allows them to shape Drupal to behave exactly as they desire - in fact, it's probably the main thing they need to do since any other functionality could be contained in a hidden module rather than implementing runtime hooks in the profile itself (as D7 lets profiles do), but that's another story.

Given that, this issue seems to make sense; it should be possible to turn off an installation profile or switch to a new one via the UI. A challenge here is that any modules that ship with the profile are going to completely disappear as soon as the profile is turned off; somehow we have to deal with that. Also, in line with Sheldon Rampton's comment, "installation profiles" may not be the best term given what these things actually do post-installation... Do we have to use a different term in the user interface ("distribution", or something else?) in order for this to make sense?

Hm, it looks like I was mistaken. I was under the impression that modules listed as dependencies[] in an installation profile's .info file could not be turned off unless you first commented out the dependencies[] line in the .info file. I guess I was wrong about that. However, I still think there is some value in trying to separate the "installation" and "profile" parts of "installation profiles."

As I think back now about how I got the idea that module dependencies of installation profiles cannot be turned off, I'm remembering that the project I was working on involved porting an existing Drupal 6 website to Drupal 7 and then trying to convert it to OpenPublic. In order to do so, I created a module based on the installation profile which had a lot of the same dependencies and script steps. I think it was that module which created the dependencies that I could not turn off. However, I would not have had a reason to create that module in the first place if there had been a way to run the OpenPublic installation profile on an already-existing website.

I guess the point I'm getting at is that I think the "installation profile" should be as minimal as possible and should only contain actions that would only be undertaken when initially creating a website. I'm envisioning maybe breaking "installation profiles" as currently designed into two parts: an "installation profile" and a "configuration profile." The "installation profile" would run at the time of installation, but the "configuration profile" could be triggered to run later if desired. Normally the "installation profile" would trigger the "configuration profile," but this would provide more flexibility for people in situations like mine who have already-existing websites where they want to adopt the same configuration.

I can see the value in being able to "uninstall installation profiles," but I think there's also value in making it possible to "install" installation profiles at a moment in time later than the initial site installation.

Somehow, I disagree with the entire proposed solution. ;)

IMHO, the idea to expose install profiles as modules was a very bad and utterly bogus one in the first place.

The way this is currently implemented is a giant hack. It breaks proper discovery of install profiles, it disallows install profile inheritance, it confuses users in the UI, and lastly it resulted in almost impossible to reproduce bugs.

After diving into this area some more recently, I seriously believe we should revert that entire design to the one of D6- and created a separate bug report for that:
#1676196: Install profiles are registered as modules

I just wrote a blog post on how to go from an install profile to vanilla drupal. It's a good place to start if you're trying to get out of a relatively simple install profile.

Here's a big +1 to the profile improvements coming in 8. :)

#10 was very helpful. I'm sure this is a common scenario.

Following from #10, the Profile Switcher module is now available for switching install profiles in D7: https://www.drupal.org/project/profile_switcher

I think install profiles are still a weird concept.

#6 (Sheldon Rampton, 12 years ago)

I'm increasingly of the opinion that there is a significant design flaw embedded in the current concept of "installation profiles."

"Installation" is something that happens once, and only once, when a website is first created. I think it is inherently problematic, therefore, to use installation profiles to both perform initial setup and to provide site configuration after the initial setup has been completed.

There is also the scenario where a team works on a project without sharing a database dump.
Perhaps during an early phase of development, or there are other reasons.

Such teams will currently run into the problem where install from existing config does not work if the profile contains a hook_install(). See #2982052: Allow an install hook in profiles installing from configuration.

For my taste, after initial installation, the concept of an install profile seems quite useless.

The main purpose of an install profile is to guide the initial installation, and (what currently doesn't work so well), additional non-configuration setup when installing from existing config.

An install profile _can_ be a container for modules and themes in a distribution.
However, I don't really see a benefit from this: It turns a distribution into an island or prison, instead of something you can grow out of.

I support this issue and the one I linked above, but long term maybe we should rethink this concept.