[meta] Profile extension improvement plan [#3576425]

Problem/Motivation

Profiles are in a confusing place in core. Let's define what they do that can't be done elsewhere and either replace that functionality or better define how and when to use profiles.

Profiles can currently do the following (non exhaustive and not in a specific order)

Define a distribution ( prevents selecting a profile )
Define install time theme
Define hook_install_tasks and hook_install_tasks_alter
Provide a list of modules and themes to install during Drupal install
Provide configuration for modules and themes
Override default configuration from modules (even once an install is finished)

I think the first step in this cleanup is to remove the profile selection form: #3520028: Remove support for selecting install profiles via the UI installer
The above issue means we need to provide a way to define which profile to install, this is one of the main features of distributions.
The other feature of distributions is the ability to define which theme to use - we should replace the ability to choose the theme shortly after or as part of that issue.

Steps to reproduce

Proposed resolution

Remaining tasks

Find place for profile docs
Document keep_english
Document #3605551: Allow install profiles to be automatically uninstalled

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

Comment #1

1 March 2026 at 20:08

nicxvan created an issue. See original summary.

Comment #2

nicxvan commented 1 March 2026 at 20:12

Issue summary:

View changes

Comment #3

nicxvan commented 2 March 2026 at 03:30

Title:	[meta] Profile improvement plan	» [meta] Profile extension improvement plan
Issue summary:	View changes

Comment #4

catch

he/him

English

commented 6 March 2026 at 15:49

Cross-linking #2876001: Installerless Drupal. We are still nowhere near the point of being completely 'installerless', but I think it would be feasible to move towards something like the following:

1. Choose language and submit the database settings form (or just the database settings form if we decided that this and only this could be untranslatable).

2. As soon as the database settings form is submitted, Drupal is 'installed' and you land on a wizard. This wizard would be on a route or custom controller like update.php, fully installed site, from there you get language settings, site template selection, things like the site name etc. Once you submit the wizard we set a flag in key/value so you can't get back in again.

So more or less replacing the 'late installer' with a wizard and hopefully we'd be able to simplify the early installer a lot (but wouldn't need to finish that to bypass the late installer, so that could happen in parallel).

With ddev, the Drupal CMS desktop app, and any other system that pre-fills settings.php, you never see #1 anyway so it would be an instant redirect to #2.

We'd still need a way to pre-set a distribution and theme before the first step of #2, but all the other features could be (re-) implemented as normal Drupal APIs.

Comment #5

phenaproxima

he/him

English

Massachusetts

commented 20 May 2026 at 13:34

As soon as the database settings form is submitted, Drupal is 'installed' and you land on a wizard.

It is worth mentioning that this is what the Drupal CMS installer effectively does, as of version 2.1.0.

The installer is still a profile (since that's the only way to hook into core's install process), but it front-loads the initial database set-up so that the rest of the profile can act as a wizard operating in a fully booted, minimally installed (i.e., only required modules) Drupal environment.

Core could get there too if we did at least these two things: