Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
There's still multiple bootstrap phases, most of them are very thin now, and they provide no advantage compared to previous releases where you might want to do a partial bootstrap in a utility script or similar, it ought to be possible to consolidate down to three overall steps without major changes.
1. Pre-kernel stuff + the kernel itself.
2. Page caching.
3. Everything else.
Comments
Comment #1
andypostNice idea! Suppose #2021959: Refactor module handling responsibilities out of DrupalKernel should in first.
Comment #2
Crell CreditAttribution: Crell commentedI fully support this; can this happen before the watchdog/PSR-3 issue picks back up?
Comment #3
catchYes I don't see any real interdependency. watchdog is currently not going to try to invoke hooks until modules are available, so that's bootstrap-level independent in terms of calling if not what it ends up doing.
Comment #4
andypostI think a different set of steps because:
1) configuration needs own init for index|authorize|statistics and update|install - first step
1.1) kernel creation mostly done separately - no reason for step
1.2) page cache should be a service that works only in index.php and not maintenance mode
2) database and variables - should be combined, there's a some of spaghetti code in
theme.inc
andupdate.inc
seems better left a separate step3) code and full - should be combined so legacy could be removed latter
Also there's some simpletest bits but they affects mostly configuration
The good idea pointed in #2062463: allow page cache cid to be alterable - we need page cache only for 'prod' kernel
Also filed #2094335: statistics.php needs a lower bootstrap level to minimize DRUPAL_BOOTSTRAP_VARIABLES usage
Comment #5
larowlanLets see where #2016629: Refactor bootstrap to better utilize the kernel ends up first
Comment #6
neclimdulI didn't know about this issue, but these 3 steps aren't far from where the bootstrap refactor ended up.
1) Pre-Kernel. Request creation, some environment sanity checks, error_handler registration, and Settings load.
2) Kernel Boot. Mostly container init(reading built container from disk and registering some synthetic values like the request). Also registers new classloader, starts timer, loads legacy includes.
3) A call to handlePageCache() delivers cached pages. Since this is split, a front controller can choose to skip it and can handle() directly though.
4) "everything else" happens in preHandle() by calls to handle() or prepareLegacyRequest(). This includes loading modules, setting up filestreams, and registering legacy globals.
Comment #7
donquixote CreditAttribution: donquixote commentedI think this becomes obsolete if we decide to go for
#2272129: [meta] Introduce a low-level DIC to organize low-level services
#2279423: Low-level DIC for low-level services: Testing grounds
https://github.com/donquixote/drupal/compare/D8-2279423-16-low-level-DIC
(this is only a starting point)
(all including #2016629: Refactor bootstrap to better utilize the kernel)
If "core services" such as the Kernel, or different pieces of the Kernel, are lazy-created when they are needed, or when other core services depend on them, then we no longer need to manually maintain a bootstrap order, and worry about whether component X is already initialized. Instead, the order of things being initialized will naturally maintain itself based on component dependencies.
The reason we would not do this in the main container is that the main container may have yet to be created. This is why I propose a second container for low-level / bootstrap stuff.
To have a look at the dependencies as they are currently sliced up in the preview code:
https://github.com/donquixote/drupal/blob/D8-2279423-16-low-level-DIC/co...
So, in index.php you could write:
(new CoreServices)->Container->get('my.service')->doStuff();
And it would do all the bootstrap for you: Choose a site directory, etc.
(this is not what the preview code does in index.php atm, but this is because I did not want to rewrite everything at once.)
Of course, you usually only want to have one instance of CoreServices. But this is only because we still have so much global state. If all of that were cleaned up, we could have as many instances of CoreServices as we like (*), which would be great for unit testing.
(*) with some limitations, because we cannot define two versions of the same class, e.g. from different versions of a module in different site directories.
EDIT:
Removed some text which I think goes too far for this post. I hit submit too quickly.
Comment #8
andypostis this obsolete now?
Comment #9
Crell CreditAttribution: Crell as a volunteer commentedIt probably is obsolete. Do we even have bootstrap steps anymore at this point?
Comment #10
neclimdulMore or less yeah we've pretty much squashed it at this point. At least the specific concerns in this issue have been addressed.