Closed (won't fix)
Project:
Drupal core
Version:
8.0.x-dev
Component:
bootstrap system
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
18 Jan 2014 at 16:25 UTC
Updated:
29 Jul 2014 at 23:17 UTC
Jump to comment: Most recent
Comments
Comment #1
sunJust 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.
Comment #2
chx commentedI 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.
Comment #3
msonnabaum commentedIn 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.
Comment #4
Crell commentedThe 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)
Comment #5
chx commentedSo, you are not interested in having Drupal any more.
Comment #6
larowlanRelated #2016629: Refactor bootstrap to better utilize the kernel
Comment #7
tstoecklerI 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:
with
(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.