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

andypost’s picture

Crell’s picture

I fully support this; can this happen before the watchdog/PSR-3 issue picks back up?

catch’s picture

Yes 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.

andypost’s picture

I 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 and update.inc seems better left a separate step
3) 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

larowlan’s picture

Issue summary: View changes
Status: Active » Postponed
neclimdul’s picture

I 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.

donquixote’s picture

I 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.

andypost’s picture

Status: Postponed » Active

is this obsolete now?

Crell’s picture

It probably is obsolete. Do we even have bootstrap steps anymore at this point?

neclimdul’s picture

Status: Active » Closed (fixed)

More or less yeah we've pretty much squashed it at this point. At least the specific concerns in this issue have been addressed.