[meta] Refactor the installer, (multi)site management, and pre-container bootstrap

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Wanted to bump 1 more time.

I'm working on a blogpost that ties this in to some other things that exist in Drupal Core, so I believe this issue is still relevant. Depending on how we structure the work we may close this as a duplicate of something else, but for now I think it's still a useful overarching issue.

The blog post is done and can be found at https://web.archive.org/web/20250908093711/https://www.alexandervarwijk.... (Web Archive Link).

I don't currently have a proposal for how we might tackle this issue. However, if we view this issue within the context of the broader componentization of the DrupalKernel then I do expect this issue to become much easier. With the changes described so far, we're moving a large amount of logic out of the Kernel.

Having these components outside of the Kernel will make their true dependencies clearer and makes it easier to change how they're instantiated or introduce new components altogether. For example we may be able to move the building of the container out of the Kernel, setting only certain requirements for the parts of the container that the Kernel itself needs but leaving other aspects of the container up to the application.

This is a discussion that fits into the broader dialogue of how we can leverage Drupal for more complex applications. A long running application that may perform background tasks or handle multiple Drupal requests at once for example may need its own container to set-up the socket server or other services outside of Drupal. By rethinking where the container is built these applications and the multiple Drupal requests that it handles, may be able to build the container only once*.

* Many Drupal services currently rely on handling only a single global request.. For example the current.user service. In order to make the container truly reusable across requests Drupal would need to introduce a "task" (e.g. "request") concept that parts of the code can use to get the current user.

Adding ✨ Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments Active as related issue because it provides a path towards doing set-up before the DrupalKernel is loaded without requiring end-users making constant complex changes to their application entry points.

I think it makes sense to keep this issue open.

Adding related issue.

+1 to keep this open