Problem/Motivation

The first line of index.php is to instantiate the autoloader. This is Drupal's primary class loader. Settings.php can then swap it out for a different one (e.g., add a decorator) by setting its $class_loader variable. After DrupalKernel::boot() is finished, this class loader is available to all code via \Drupal::service('class_loader').

Ideally, code that runs before DrupalKernel::boot() is finished would also have access to this same class loader. This primarily includes code that's part of the database system, such as the static methods of the Database class, and the code within database drivers (core and contrib). However, it also includes code that's run by settings.php itself (as well as sites.php in the case of a multisite). And, in the case of a cold start after a cache clear, this could also include all code that's involved in compiling the container, such as all of core's and contrib's service providers and compiler passes.

The reason it would be ideal for all Drupal code to access the same class loader, regardless of when during the bootstrap/request it runs, is so that if settings.php or other code does decorate or mutate this class loader, it affects all classes loaded by Drupal. For example, if there's code that adds logging, or that converts relative paths to absolute paths, or relocates to alternate paths, these changes should apply to all of Drupal's not-yet-loaded classes. Early bootstrap code shouldn't have to resort to registering a separate autoloader, because then anything added to that autoloader wouldn't receive the changes made to the primary autoloader.

Steps to reproduce

Proposed resolution

Add a \Drupal::classLoader() method that can be called at any time during the bootstrap / request.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#2 3292014-2.patch4.38 KBeffulgentsia

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

Status: Active » Needs review
StatusFileSize
new4.38 KB
daffie’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

The patch looks good. Just 1 minor nitpick:

+++ b/core/lib/Drupal.php
@@ -148,6 +162,23 @@ class Drupal {
   public static function setContainer(ContainerInterface $container) {
...
+        throw new \LogicException("When \Drupal has a class loader, the container must have the same class loader.");

The docblock needs to be updated for the new exception.

We also need some testing to be added. Specially when are working with the new static variable $classLoader. Also when the new exception is being thrown. Can we also add testing for "Add a \Drupal::classLoader() method that can be called at any time during the bootstrap / request."

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.

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.