At the moment, if you install core via the UI installer, you can choose install profiles, but not a recipe.
If you install Drupal CMS, then Drupal CMS's installer + https://www.drupal.org/project/recipe_installer_kit takes over the installer and removes that form. But this is really a workaround for the core installer not supporting this workflow.
Core already has the standard profile as a recipe, and it's possible to install minimal or umami via drush.
So... I think we could remove the install profile selection from the installer, and if you install just core, you would get the standard install profile as a recipe. Eventually we can add project browser to core and you could install a site template/individual recipes directly from core (if we want).
If you have a distribution, you already don't get an install profile choice in the installer, because the existence of a distribution skips that set.
So the only feature this would remove would be installing arbitrary install profiles via the UI that aren't distributions, and it would still be available with drush/quickstart etc.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | Screenshot 2026-02-03 at 13.28.00.png | 564.93 KB | gábor hojtsy |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
phenaproximaI'm generally +1 for this, because I like anything that streamlines the installer and gets people up and running more quickly.
Comment #3
catchComment #4
catchRe-titling, because pre-selected profiles (pre-filled settings.php, distributions), will still be supported. The only thing we'd be removing here is the form/step for install profile selection.
Comment #5
gábor hojtsyI think Drupal CMS 2.0 will change from the recipe picker to a site template picker with the built-in site templates as options. So I would not yet go towards what CMS 1.0 does :) In a way the site templates are more similar to the install profiles (in concept, not in technology!) than recipes were :) I don't think site templates will be install profiles at all though, so I think the install profile selector will not come back in CMS for sure.
I opened #3523324: Deprecate and remove the Umami demonstration profile from core, make it a contributed site template to free Umami from core and revitalise it in contrib as a contrib site template showcase :)
I think as long a we have Umami in core only (and not in contrib), it would be sad if there would be no UI to select it. After all we created Umami for those that do not necessarily work well with a CLI.
Comment #6
catchIsn't that already being fulfilled by Drupal CMS now though? Especially given it's the default download on https://new.drupal.org/download
If we're not going to convert Umami to a recipe in core, then it means we'll be blocked on removing install profile support from core until it's fully implemented in Drupal CMS, which could be another couple of years potentially.
Comment #7
gábor hojtsyGood point, I think the default site templates planned for Drupal CMS 2.0 would serve the same purpose in an updated way with Experience builder, etc. So at that point Umami is superseded already. Yeah. This would probably mean removing the install profile selection in 11.3 (2025 december) and deprecate Umami in core at the same time?
Comment #8
catchI think 11.3 is reasonable timing. We won't be able to fully deprecate install profiles until we've added support for some of the things distributions can do to site templates, but it would be good to be able to work towards it.
Comment #9
gábor hojtsyShould this also do this issue in 11.3 or in Drupal 12? I don't know what other contribs may depend on the install profile selector (ie. they would come with multiple install profile selector).
Comment #10
catchI think the installer batch steps and form structure are something we can change in a minor release, if a distribution is shipping multiple install profiles in a single distribution, they would be able to add the page back again (if they're not already replacing it entirely).
Comment #12
catchSelectProfileForm.php deletedI didn't know the gitlab UI could write poetry.Comment #13
phenaproximaI'm working on this.
Comment #15
gábor hojtsyI think we agree on the following:
Drupal is moving from a potentially multi-install-profile installer to a single install profile installer where the options are not install profiles but site templates. This does away with problems with install profiles (lack of inheritance, lack of composability, lock-in). It will still be possible for the foreseeable future to install with whatever one custom install profile you have, so full-on products can utilise that to install the product they are providing. Such as Open Social for example.
Drupal CMS now ships with this site template picker currently:
More of these site templates will be available later this year on drupal.org.
As a Drupal core product manager, I thought I already removed the signoff tag, but I didn't :) So removing now.
Comment #16
phenaproximaThis was really, really hard to do.
The installer's code is incredibly complicated, and its tests are equally hard to grok. The many paths through the installer are not really clarified by how opaque the tests are.
Nonetheless, a lot of difficult trial and error helped me find the way here. This completely removes profile selection from the UI -- I tested it out and, if the database is preconfigured, this is damn near a one-click install. Jeepers, Batman!
Functional JavaScript tests are still failing but I believe they are unrelated (or at least, I don't see how they could be related) to the changes here.
Comment #19
nicxvan commentedI created https://www.drupal.org/project/profile_selector as a proof of concept for how to add this feature back for people that need it.
Mainly to test that it would work as expected.
Comment #20
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #21
gábor hojtsyComment #22
gábor hojtsyMR is green again. I reviewed and looks good to me, although I admit I don't understand all the bits especially with language configuration in the installer there seem to be some tricky parts.
Re the issue scope, this is what the summary has (emphasis from me):
I don't think it is in the scope of this issue after all to remove the standard profile too and instead apply the recipe, that would be a followup. But I think not having twice the same thing in core would be useful and to keep install profiles more as a tested API and not actively used by core :) Needs a followup IMHO though.
Comment #23
phenaproximaFiled a postponed follow-up for the installer to default to the Standard recipe: #3591080: [PP-1] If no distribution or alternate profile is chosen, the installer should default to applying the Standard recipe
Comment #24
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #25
phenaproximaLies and slander! The MR is up-to-date and, last I knew, passing tests.
Comment #26
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #27
phenaproximaComment #28
nicxvan commentedI think this is ready!
I know Gábor has been involved, I'm not clear if he officially signed off with his product manager hat on or not though.He did in comment 15.
I wrote the helper module to confirm it can be added back in if necessary I will promote that once this gets in.
This probably warrants a CR though.
Comment #29
gábor hojtsyI totally support this form a product manager view. We either need to do this or #3590801: Mark the minimal profile hidden in the UI (developers can still install with drush), but #3590801: Mark the minimal profile hidden in the UI (developers can still install with drush) is more of hack that would make the step go away because there is only one visible profile left :D (And would make the discoverability of Minimal harder since people would explicitly need to know about it even in the CLI). So with the ultimate dev experience in mind I prefer this solution if we can land this, and #3590801: Mark the minimal profile hidden in the UI (developers can still install with drush) secondary if we can't land this :) But let's land this :)
Comment #30
phenaproximaChange record drafted: https://www.drupal.org/node/3595589
Comment #31
nicxvan commentedI added a link to the example on how to add it back as well.
Comment #32
catchEither I'm misunderstanding something or the MR is bringing back a base test class that should be removed in main - could be a rebase issue.
Comment #33
phenaproximaI think that was probably a rebase issue, since it's an abstract class with no subclasses. Removed. Since this was just MR gardening, restoring RTBC directly.
(Edit: I pushed the commit but it's taking a while to show up. Probably some GitLab slowness.)
Comment #35
catchCommitted/pushed to main, thanks!
This will need a backport MR for 11.x
Comment #37
longwaveAre we actually going to change this in 11 now? We're too late for 11.4 and given 11.5 will be a maintenance minor it feels quite a big change to bring it back there too?
Also is there a chance someone is actually using this for some kind of product based on Drupal, in which case it's a BC break for them? Feels unlikely I guess.