Problem/Motivation
A philosopher once said:
Don't it always seem to go
That you don't know what you've got 'til it's gone
In this case, the thing we lost that we didn't know we had is the ability to theme the installer. It is not loading the theme, or themes, it needs to. Drupal CMS is severely affected by this because of its extensive installer modifications, but vanilla core is too.
The problem is that theme hooks, which can now be object-oriented, are not executed because they are not discovered by the theme hook collector. They are not discovered by the hook collector because the hook collector depends on the container.themes container parameter being accurate, based on what's in DrupalKernel::$themeList, and...it's not. It's an empty array.
But that's not actually true; the installer does indeed load the necessary chain of themes, in drupal_maintenance_theme(). But by that point, it's too late: the installer kernel has been fully initialized, and the hooks have been (not) collected. Result: one very sad-looking installer.
Steps to reproduce
Just spin up Drupal 11.3.0-rc1 and visit the installer to weep gently as you behold this sorry excuse for a page:

Proposed resolution
1. Add the profiles earlier to install state so we can use this info during container booting
2. Copy the logic from _install_select_profile() so we can work out the profile and get info while booting the container
3. Resolve the installer theme and add to the container if necessary.
Remaining tasks
Fix it with a test.
User interface changes
None, unless you count "restoring the decent UX that we previously had" as a change.
Introduced terminology
None.
API changes
None.
Data model changes
None.
Release notes snippet
None necessary, this is squarely a bug fix.
| Comment | File | Size | Author |
|---|---|---|---|
| 11.3.0-installer-sad-trombone.png | 70.06 KB | phenaproxima |
Issue fork drupal-3562319
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
nicxvan commentedComment #4
phenaproximaWrote a regression test here, but I think @nicxvan is better suited than I to fix this. Unlike me, he understands this stuff.
Adding this snippet in
DrupalKernel::compileContainer()will make the test pass:Comment #7
nicxvan commentedComment #8
nicxvan commentedComment #9
nicxvan commentedComment #10
nicxvan commentedComment #11
nicxvan commentedComment #14
alexpottThis blocks the release of 11.3.0 too!
I've added a new MR that includes and improves on the test case. Plus the approach works. It almost certainly results in more directory scanning and yaml parsing during the install but that might be something we have to take on the chin for 11.3.0 and then work out how to fix in a bigger refactor of the installer.
Comment #15
catchManually tested !14080
Claro loads on the first page with stock head.
If you hack standard.info.yml to add this courtesy of @alexpott:
Then the first page of the installer loads in Olivero.
I hit a weird issue with Olivero as the distribution theme where I then got a fatal error the first time the front page of standard loaded (second page was OK). I think this is... not the fault of the MR but the hacky way of testing it. With stark as the installation theme, first page of standard was fine.
Didn't profile but install was still pretty snappy, we can live with the extra YAML parsing here, and try to use this issue as motivation to modernise some of this stuff sooner than later.
Comment #19
alexpottComment #20
phenaproximaThis fixes Drupal CMS. Ship it.
Comment #21
nicxvan commentedSorry, a couple questions on the MR, one is important I think.
Comment #22
nicxvan commentedQuestions answered, this looks great!
Comment #26
nicxvan commentedReviewed the two commits since RTBC, still RTBC.
Comment #29
catchCommitted/pushed to 11.x and cherry-picked to 11.3.x, thanks! The fact we found at least two undiscovered bugs while fixing this one shows how arcane this stuff is.