Move the theme initialization into its own service.

Combine this with the theme request listener I have in #2016629: Refactor bootstrap to better utilize the kernel and it gets cleaner still, no need to init theme in bootstrap anymore!

1. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   + * Contains \Drupal\Core\Theme\Initialisation.
   

   You're going to hate me but don't we have to use American spellings? Initialization.

2. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   +  public function initThemeSystem() {
   

   Needs a docblock

3. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   +   * This function is useful to initialize a theme when no database is present.
   

   Can this be expanded on, as the method name doesn't immediately make sense given this comment.

4. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   +   * @param \stdClass $theme
   

   Needs a short summary

5. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   +   * @param \stdClass $base_theme
   

   Can you elaborate on the expected format of these objects?

6. +++ b/core/lib/Drupal/Core/Theme/Initialisation.php
   @@ -0,0 +1,269 @@
   +      $theme_engine = $theme->engine;
   +      if (function_exists($theme_engine . '_init')) {
   +        foreach ($base_theme as $base) {
   +          call_user_func($theme_engine . '_init', $base);
   +        }
   +        call_user_func($theme_engine . '_init', $theme);
   +      }
   +    }
   

   General comment: boy the theme system could do with real objects and some interfaces (not related to this patch).

   class FooTheme extends Bartheme {
     public function initEngine() {
       parent::initEngine();
       $this->themeEngine()->init($this);
     }
   }
   // ...
   $theme->initEngine();
   

Hm. Some methods of the new class do not really belong to its responsibilities, IMHO.

For consistency with ModuleHandler, at least the loading of themes belongs into ThemeHandler::load(), no?

For the initialization methods, I actually wonder whether a standalone service is the right architectural tool? — Technically, the theme needs to be (re-)initialized for every Request, and ideally only on-demand upon the first call into _theme() & Co.

Lastly, the addition of theme assets, shouldn't that actually be a Response event listener, limited to HTML responses?

I think we need to rethink the proposed approach here.

This service is just a nice separation of concerns.

Yes, there is a separation of concerns by introducing a separate service, but we're running into the exact same + major trap as with the current_user service here:

The theme depends on the current request.

How do we ensure that the correct theme is (re-)initialized for a particular request?

In addition, the D8 [contrib] port of the removed core feature of user-specific themes enhances/replaces that dependency with a dependency on the current_user service.

This works theoretically if we remove the support to alter stuff in themes.

That is definitely fine — the one and only reason for why drupal_alter() includes themes is to allow themes to participate in theme related hooks.

Any alter hook that is invoked before the theme layer is initialized is actually not expected to involve themes. The only reason for why themes participate currently is "KISS" — it simply would have been too much extra code/logic in a too frequently called code path to check whether themes are eligible to participate in a certain alter hook.

Various people actually raised major concerns against the (current) proposed solution of simply including themes in all alter hooks, because that apparently allows themes to even participate in hook_query_alter() and similarly scary alter hooks that you definitely do not want to see in any theme. ;-)

Yeah probably a kernel view subscriber, at which state we do have the fragments on which we can attach those assets.

That sounds much more adequate!

I wasn't sure on which of both issues to comment, so #2167619-17: Replace many of the global $theme/$theme_key with a call to the theme negotiator.

Perhaps, shall we create a new theme system meta issue? Apparently, there are a lot of fundamental architectural questions to figure out, and I'd rather like to do that before further time is spent on patches.

Updating tags per Issue tags field and Issue tags -- special tags and for issue #3565085: Drupal core issue tag cleanup.