Allow install profiles to be run after site creation

[mikemccaffrey]

It seems potentially useful to allow install profiles to be run, not only at site creation, but also at any point afterwards. That would make them useful for publishing "recipes" which would mostly involve the creation of site building items such as content types, views, and fields. However, they could also be used to install contrib modules, themes, and layouts where necessary.

This would allow users to use a install profile even after they have installed backdrop and otherwise started building their sites. And it would allow them to run more than one install profile, each of which would provide a different set of functionality.

[mikemccaffrey]

From @jenlampton in backdrop-ops/backdropcms.org#46 (comment):

I prefer the features analogy better for these - it's a suite of modules, themes, layouts and config, that can be enabled and disabled. There's a much larger use-case for features than there is for profiles, and I think that's what people will really want.

There were many assumptions baked into Features that never held up to practice in the real world. For example, they did allow you to create a bunch of pre-determined site building items and configuration settings (and disable them all afterwards if you wanted). However, they assume that you would not make any changes to the way the Feature module set things up, and if you did make any, the Feature would immediately be displayed as overridden and you would no longer be able to download updates to the feature from the publisher without losing your local changes. That led Features to only really be used by people who published their own features from a dev site, so they could be updated with any custom changes that need to be made on live.

Install profiles, on the other hand are viewed more as a starting point. You download them and use them to create a blog or a conference site or such, but they you can customize the site as much as you want without worrying about having things overridden by any upstream changes to the package.

Install profiles are not able to be disabled and removed as easily as features, but that isn't that big of a deal, since any modules, content types, views, taxonomy terms and such that were dowloaded or created can be easily removed individually. And if people did want to install a profile, we could support a function that just deletes things that have been created.

[jenlampton]

Install profiles are not able to be disabled and removed as easily as features, but that isn't that big of a deal, since any modules, content types, views, taxonomy terms and such that were dowloaded or created can be easily removed individually.

I'm not sure I agree with this. I've spent a lot of time struggling with sites that were using some crazy install profile (because that's what the poor owner / developer was sold) and un-doing it is not as simple as removing the modules / themes because of all the other crazy things that are often done at install time.

I think we have an issue somewhere about reevaluating how profiles work (now that we are in the age of composer) that would be relevant here too, but I can't find it atm. (I found this issue instead!)

FTR I don't have a strong opinion what we call the thing that does this job (profile / feature / package) but I would be weary of starting with something like profiles, as they might need a lot of changing to get them to work as a feature as well. We are already planning on a lot of changing profiles in 2.x to make them less janky than they are today, is that too much change?

Is adding another similar concept worse? :) I'd love feedback from the larger community on this topic, as I think what people do with Backdrop in 1.x should help steer our direction for 2.x :)

[mikemccaffrey]

I'm not sure I agree with this. I've spent a lot of time struggling with sites that were using some crazy install profile (because that's what the poor owner / developer was sold) and un-doing it is not as simple as removing the modules / themes because of all the other crazy things that are often done at install time.

Well, one benefit of allowing multiple profiles to be run on a site, is that they can be broken down into smaller pieces, each of which can be run or not depending on the needs of the site. And, hopefully, that means that there will be less cruft included in large single profiles.

As far as crazy things that are done at install time, we should discourage those things from being done as much as possible no matter what. Perhaps we should require install profiles to list out all the things they are adding and changing, so people will know how their site will become different than a standard Backdrop install.

Should we table this discussion for the 2.x release, since it would be a big architecture change, even though it could probably done without breaking API continuity?

[klonos]

I believe that we can close this issue here in favor of the various initiatives around recipes. See:

• [META] - Issues Related to Recipes #5240
• [META] Recipes 2.0 (a.k.a. the "Master Chef" initiative) #6595

Besides, installation profiles and distributions come with a "lock-in" effect, which we are trying to move away from.

Our telemetry stats show very little usage of custom installation profiles BTW. Currently 99% of Backdrop sites are using the standard installation profile (623 out of 628 sites).