Problem/Motivation

Bootstrapping Drupal should be doable by including bootstrap.inc and calling drupal_bootstrap(). That's what it is called: bootstrap. Right now you also need to add core/vendor/autoload.php which basically violates encapsulation.

Proposed resolution

Move this include into drupal_bootstrap where it belongs.

Remaining tasks

None.

User interface changes

None.

API changes

Your custom scripts can remove one line of code.

CommentFileSizeAuthor
bootstrap.patch2.11 KBchx

Comments

sun’s picture

Just for completeness, this came up in #2176151: rebuild.php does not include /core/vendor/autoload.php

The change notice https://drupal.org/node/2080891 refers to #2038135: Use the Composer autoloader to make everything simpler as the original issue that introduced the separate inclusion of autoload.php.

There might have been a technical reason for the separate include line — off-hand, I'd assume to make it possible to use a different base autoloader than Composer's, but I'm not familiar with that issue.

Alternatively, the idea might have been to get rid of bootstrap.inc and drupal_bootstrap() altogether.

I do not have an opinion myself on this. I don't really mind an additional file inclusion for the base autoloader.

chx’s picture

I do mind and seriously so -- why would anyone need to bother with what choice we made to use as a classloader? This is arguably even major because it's a regression from Drupal 7.

msonnabaum’s picture

Status: Needs review » Closed (won't fix)

In order to move any parts of bootstrap to classes, the autoloader needs to be the very first thing. Not having this has made several refactoring patches I've worked on unnecessarily difficult. If anything, including bootstrap.inc is polluting the environment by including code that may or may not be called.

Crell’s picture

The longer term goal is to eliminate drupal_bootstrap().

If you wanted a different front-controller to Drupal, you'd include the autoloader, instantiate your own kernel, and run it. If you want to reuse the kernel core has but with a different set of arguments, cool, do that. That's consistent with Symfony fullstack and Silex, at the very least.

Since we've eliminated a couple of our alternate front-controllers already in D8 (eg, cron.php), the use case for needing to do that is smaller anyway. I don't think the use case here (include bootstrap.inc, drupal_bootstrap(), and run my own custom stuff) is all that meaningful anymore given the changes to the architecture and the work that's been done to make components more loosely coupled. The idea of needing to "bootstrap Drupal" before you can do anything is outdated to begin with. You need to assemble the components you care about.

Edit: Also, what Mark said. (Crosspost)

chx’s picture

So, you are not interested in having Drupal any more.

larowlan’s picture

tstoeckler’s picture

The idea of needing to "bootstrap Drupal" before you can do anything is outdated to begin with. You need to assemble the components you care about.

I don't think this statement is even remotely true. We will always need some sort of bootstrap process in Drupal. I.e. in contrast to Silex/Symfony/... you need to know which modules are enabled, and everything that follows from that.

I agree that in the long-run we want to convert:

require_once __DIR__ . '/vendor/autoload.php';
require_once __DIR__ . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

with

require_once __DIR__ . '/vendor/autoload.php';
$kernel = new DrupalKernel();
$kernel->init();

(or similar, please don't nitpick the actual code), but saying that we don't need any bootstrap process other than autoload.php just because Silex and Symfony can get away with it is just wrong.