Introduce new bootstrap phase for initializing class autoloading

Having the autoloader earlier in the bootstrap means we can move some of the bootstrap to PSR-0 classes in follow up patches. Patch applies cleanly, code looks good, tests pass.

+++ b/core/includes/bootstrap.incundefined
@@ -2284,22 +2294,12 @@ function _drupal_exception_handler($exception) {
 /**
- * Sets up the script environment and loads settings.php.
+ * Initialize the class autoloader and register core namespaces required for
+ * early bootstrap.

The docblock for this new function needs some work.

The first line should start with an active verb and it should be no more than 80 characters.

You might want to add a second explanation line (after an intervening space) that expands on what this phase of bootstrap does.

+++ b/core/includes/bootstrap.inc
@@ -2147,6 +2152,7 @@ function drupal_anonymous_user() {
+    DRUPAL_BOOTSTRAP_AUTOLOADER,
     DRUPAL_BOOTSTRAP_CONFIGURATION,
     DRUPAL_BOOTSTRAP_PAGE_CACHE,
     DRUPAL_BOOTSTRAP_DATABASE,

The new phase name "autoloadER" doesn't seem to be in line with the other phase names.

What about DRUPAL_BOOTSTRAP_AUTOLOAD ?

+++ b/core/includes/bootstrap.inc
@@ -2284,22 +2294,14 @@ function _drupal_exception_handler($exception) {
+ * Initializes the class autoloader.
+ *
+ * Makes class autoloader available to all subsequent bootstrap phases.
+ * Registers both the Symfony and Drupal namespaces with the autoloader.

This additional description doesn't provide any further information - except for explicitly mentioning Symfony and Drupal namespaces, but that's rather a code/implementation detail.

I'd recommend to drop the description and just keep the summary:

Initializes the class autoloader and registers namespaces.

+++ b/core/includes/bootstrap.inc
@@ -2284,22 +2294,14 @@ function _drupal_exception_handler($exception) {
-

The blank line here would be nice to keep for readability.

Updated with comments in #7. Replaced the description to point over to drupal_classloader() and uses "autoload" for the const and bootstrap function name.

This patch now looks good to me. I will leave to others for RTBC.

Agreed. The "autoloader" is what we're bootstrapping, just like how we're bootstrapping the "configuration".

Fixing component.

 /**
+ * Sets up the script environment and loads settings.php.
+ */
+function _drupal_bootstrap_configuration() {
+  // Set the Drupal custom error handler.
+  set_error_handler('_drupal_error_handler');
+  set_exception_handler('_drupal_exception_handler');
+
+  drupal_environment_initialize();
+  // Start a page timer:
+  timer_start('page');
+  // Initialize the conf

Two things:

- Why do these belong in _drupal_bootstrap_configuration() more than _drupal_bootstrap_autoload(), I'm assuming they were put here simply because it was the first step, now it's not. Seems like a good chance to tidy up.

- more importantly. drupal_classloader() calls variable_get(), variable_get() depends on $conf, which can be altered by settings.php, so the patch is broken as it currently stands.

I suggest we just rip out the APC option for the autoloader for the moment. We know that other changes are coming in this area. We can revisit that later when we're done breaking stuff.

As for the error handlers, I disagree. Those don't belong in autoload. If anything they'd be part of an "environment init" bootstrap phase, but really, we need to stop thinking in terms of "environment creation". (Arguably those functions could be moved to a class, then autoload that! :-) ). We don't need those for the class loader, I think, so let's punt on that for now as well.

That assumes there cannot be any errors in the autoloader code, which sounds bogus.

No, it assumes that any errors there can be handled by the default PHP error handling, because they're sufficiently rare.

andre: Those functions do not depend on $conf. The variable_get() call in the class loader setup depends on $conf. That's what I suggest we just remove and come back to later.

Might be easier to get #1424924: Use Composer for updating Symfony components (without removing Symfony code from repo) in first, because then we could simply just call drupal_classloader() during the bootstrap. Saves us a function definition.

Updating links to use markdown for readability

Unless I'm terribly mistaken, this issue is obsolete by now?

We're using the Composer ClassLoader in the meantime, which is manually included by all front-controllers before drupal_bootstrap() is called.

Unless the composer classloader does not loads modules custom classes, this issue is still not fixed, otherwise yes..!