Compared to Drupal 7, a lot of the codebase in Drupal 8 has been transformed into loosely coupled components, receiving their dependencies from a DIC instead of having to pull them from somewhere.

However, everything that comes before that still has a lot of global state, intransparent interdependencies, and nasty arrays: Installer, bootstrap, settings singleton, multisite, DrupalKernel. This makes it unnecessarily difficult to write unit tests.

The solution, as I see it, is to turn all this low-level stuff into loosely coupled components, and to introduce a CoreContainer that will manage the dependencies of these components. See #2272129: [meta] Introduce a low-level DIC to organize low-level services for an approach from a while ago.
(I am currently working on this locally)

Besides this container, we can also do some preparation steps that do not require the container.
One idea was to turn the $install_state used in drupal_install() into an object.

This issue can act as a parent for the other issues.

Comments

catch’s picture

catch
he/him
Primary language English
commented
Version: 8.1.x-dev » 8.0.x-dev

Keeping this as 8.0.x for now, looking at some of donquixote's changes it'd make core more testable including some quite fragile and security-sensitive spots.

So if there's nothing disruptive should be still OK for 8.0.x, we can always move to 8.1.x if that turns out not to be the case.

donquixote’s picture

donquixote commented

This also touches the database:
#2363315: Refactor Database:: static properties and methods

donquixote’s picture

donquixote commented

As a preparation:
#2363341: Throw exception in Drupal::service() and friends, if container not initialized yet.

Not really sure this is required for the CoreContainer architecture, but it will be nice to have it out of the way.

donquixote’s picture

donquixote commented

Created an issue for multisite / settings stuff: #2363353: Refactor / split up \Drupal\Core\Site\Settings singleton, and introduce other multisite-related classes.

Maybe we can do some preparation work there, so that the CoreContainer changes become smaller.

donquixote’s picture

donquixote commented
Related issues: +#2363881: Settings::__construct() should not write to self::$instance.

More about Settings::
#2363881: Settings::__construct() should not write to self::$instance.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

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!

smustgrave’s picture

smustgrave commented

Wanted to bump 1 more time.

kingdutch’s picture

kingdutch
he/him
Primary language English
commented

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.

nicxvan’s picture

nicxvan commented
Status: Postponed (maintainer needs more info) » Active
catch’s picture

catch
he/him
Primary language English
commented
Category: Task » Plan
kingdutch’s picture

kingdutch
he/him
Primary language English
commented
Related issues: +#3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments

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 #3313404: Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments 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.

mondrake’s picture

mondrake
Location 🇮🇹
commented
Related issues: +#3492391: Make the event dispatcher available before container full bootstrap

Adding related issue.

+1 to keep this open

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.