Fatal error: Uncaught TypeError: Drupal\Core\Extension\ThemeHandler::addTheme()

This is probably related to #3457863: YAML discovery does not take theme inheritance into account.

Is this potentially drush not setting any theme or something else setting an invalid theme? We might just need to add an isset() before calling ::addTheme() for when it's not in the list.

Same error for me with PHP 8.3

With PHP 8.2 works fine.
Thank you.

Bumping to critical since this is a WSOD.

I have tested this on PHP 8.1 and 8.2 and the error persists.

I can't conceive of how the PHP version would matter here, and I don't think it does.

@cilefen, I agree. I only mention it since there was talk earlier of a similar issue where PHP 8.3 appeared to break the sites. My comment is more of a reference.

In truth I was reacting to comment #4 above.

Cool. I also tested on PHP 8.3 and there is no change. To anyone reading this, the version of PHP 8.x is irrelevant.

Hi,

To replicate the problem by doing the following: Drupal 10.2.0 was freshly installed, updated to 10.3.6, and drush updb &drush cr was executed. But I cannot see the problem on my end. let me know how to reproduce it.

Thanks

Maybe core.extension configuration contains references to removed themes? Recent upgrade changed something and this triggers an error.

It can be checked with drush: drush cget core.extension

If there are themes that should not exist, just delete them with drush cdel core.extension theme.

@lav rai I don't think this is reproducible with a clean install, seems to be some kind of invalid configuration triggering it. Thanks for trying to reproduce though.

I've put up an MR that should get past the type error.

Could someone who's experiencing this bug try applying that as a patch, and see if that gets you past the type error? And if so, do you get any other errors about invalid/missing theme configuration?

In my case, the website was:

1. Upgraded to the latest Drupal 8 (it was built clean on Drupal 8 with content imports from Drupal 7 via Feeds).
2. Upgraded to the latest Drupal 9.
3. Contrib modules were upgraded.
4. Upgraded to Drupal 10.3.5.
5. Contrib modules were upgraded where needed.
6. Upgraded to Drupal 10.3.6. (It was released maybe a week later.)
7. The issue started.

Through all of this, the Adminimal Theme was being used and was upgraded along with everything else. There was an introduction of a dependency of the Seven theme at some point and this might be where the issue started. I just checked again and the dependency is there in Drupal 8, just didn't remember.

The error being produced has been consistent. There haven't been any other issues that appear to be related other than contrib modules with the usual updates. It felt like this one popped up at the 11th hour but I don't see anything in the upgrade process that would have caused it. Nothing obvious, anyway.

Can you provide patch file?
Thank you

I confirm that i had a missed theme.

Can't really provide steps to reproduce, had an environment with some broken out of sync config in the db that included the stable theme. Applied a similar patch to the merge request and it worked to get us out of a jam to where we could run drush and fix the site and get the config in sync.

We were also hit by this bug when migrating some D10 sites to Drupal 11.

Some themes were probably missing.

Patch was useful, thanks.

Hello, I have this error after update to Drupal 10.3, after update Drush 11 to Drush 12, which allowed this update.

I dont want to patch the core, it is not long term solution.

What to do? Will anyone fix this error?

Thank You.

@markiz,

You are correct this is not a long term solution but this is the current solution and it works well. This type of patch will be rolled into the next release (most likely).

But, this thread is about tracking down when and how this occurs. It would be helpful if you would elaborate on the steps you took that resulted in the issue appearing on your website.

The more information that can be gathered would be incredibly helpful.

Thanks!

Looking at the code committed for #3457863. It drops the array_intersect_key function which removed any themes that weren't in present in both arrays ($list and $installed_themes). The new code loops through $installed_themes array keys and then uses the value from the $list in the addTheme method. The error pops up when there is a theme in $installed_themes that's not in $list (and which would previously get removed via the array_intersect_key function). $installed_themes comes from the theme configuration in the core.extension.yml while the $list comes from a list of themes present in the codebase.

The patch catch provided adds a check to replace what array_intersect_key was doing.

However, the problem for sites encountering the error is most likely because the theme configuration settings in the core.extension.yml includes a theme which is no longer present in the codebase. This was the case for us. I see comment #12 already mentioned this.

working on logging and tests to make this a better long terms solution.

I applied below patch locally its working as expected.

Patch #26 is working fine for me. Marking this issue to RTBC.

The patch needs to be converted to an MR so that automated tests can run on gitlab.

In my case, the theme stable is a problem. I installed module stable https://www.drupal.org/project/stable and the site working again.
Some themes are not compatible with the new Drupal version.

In my case the issue was both `stable` and `classy`. I removed them on dev as part of updating to 10. I pushed all changes live but never disabled both the themes on prod before doing so thus I got the error. A simple `drush thun stable` and `drush thun classy` solved the issue for me.

I got this crash because I had the 'seven' theme installed on my site (but not active).

Patch fixes the crash, though `drush cr` now keeps saying:

> [warning] Theme seven not found.

and I don't know how to make that go away.

I got caught by this problem/error in trying to run and revise a custom subtheme of a contrib theme (Solo). All done on a local site. I searched in PHPstorm and found that I could apply the patch from Git / Patch / Apply patch from clipboard after copying the patch code from #26. An afternoon of pain quickly disappeared. Hopefully the code, or a version of it, gets applied to a future core version.

Thanks to those who contributed.

I cannot apply patch since I am not using git for drupal, does anyone have the ThemeHandler.php post patch file ?

There is now a failing test in place: the Test-only test fails without the changes and with the changes the pipeline runs all green.

I have removed the 'Needs tests' tag.

Changed the status to RTBTC.

Have added more detail to the 'steps to reproduce' section of the issue description.

Probably this should be reviewed before changing to RTBTC.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The pipeline is running all green.

It is not possible to identify from the comments which Drupal versions this bug can be tested on. It could be that a Drupal 9 to Drupal 10 update using the Seven theme would work since that theme was removed from the core codebase in Drupal 10

Comment #30 is also useful.

The remaining tasks are

• Follow the 'steps to reproduce' and manually test the fix'
• Record the Drupal versions used and the theme/ version that was removed from the codebase
• Add these details to the issue description.
• Ideally manually test with and without the fix
• If the fix works change the status to RTBTC

I ran into this problem when upgrading my personal site, https://dri.es/, from Drupal 11.0.x to Drupal 11.1.x.

I did not apply the patch but was able to fix this by doing something like:

drush theme:uninstall dries
drush config:set system.theme default claro -y
drush theme:install dries
drush config:set system.theme default dries -y

@dries did you have to make any changes to the dries theme? Did code move about? It's really odd that on 11.0.x the theme was being found and added correctly and then updating the code let to it not being found but reinstalling it fixed the problem.

Suggestions:

1. Use a skeleton custom theme in the 'Steps to reproduce': to prove that this is a bug affecting all, not certain themes
2. Still not sure on the next 'steps to reproduce'. Make the skeleton theme the default theme? disable or delete other themes before upgrading?..
3. If the bug can be fixed with several drush commands is it still a bug? Or is that what drush if for?
4. Is this bug confined to a particular composer version of drupal i.e. should steps to reproduce specify a particular version eg 'drupal-recommended'?

I didn't make any code changes.

I only had this problem on my localhost (using DDEV), but not in production (using Acquia Cloud), so it might be related to that.

@dries I suggested point 4 in #49 because I tried to reproduce this issue some weeks back using DDEV. I abandoned the attempt when it failed perhaps because i tried too big a 'leap' between versions.

I followed Drupal.org documentation to do a drupal update using composer. On that page is states,

If you are not using drupal/core-recommended but instead only drupal/core:

So there are two different types of composer update. Using the DDEV quickstart to create the drupal codebase means you are using the 'drupal/core-recommended' composer version of drupal. It would be useful to try an identical update using:

1. drupal/core-recommended
2. drupal/core

to see if the bug is reproduced in both cases.

I wonder if the theme subsystem is more prone to bugs than it might be since each theme can be

a) Installed
b) Uninstalled
c) Set to default
d) The above applies to the admin theme and the non-admin theme.

Would it not be simpler to have?:

a) Installed and therefore the default
b) Uninstalled

Similar to the simplification of module status:

Was:

a) Installed
b) Disabled
c) Enabled

Now:

a) Installed and enabled
b) Uninstalled

DDEV does have a CMS Quickstart for Drupal based on a Git clone. I am not sure if Drupal 11 gitlab clone uses 'drupal/core-recommended' or 'drupal/core'?

Based on #47 steps to reproduce could be:

1. Install Drupal 11.0.x using the standard profile.
2. Use the composer 'drupal/core-recommended' version of drupal
3. If using DDEV, follow the DDEV quickstart for Drupal 11.
4. Create a skeleton theme.
5. Set the theme as the default non-admin theme.
6. Update Drupal to 11.1.x. by following the steps in the drupal composer update documentation
7. Update the database using drush updb

Same as @dries, but I had this issue on Drupal CMS RC2 following the instructions provided by https://new.drupal.org/drupal-cms/release-candidate

ddev, unzipped, ran script (no errors), site launched shows this same error.

I'm not sure whether this is an error with D11 or D-CMS or whether to raise a separate issue, but given one is based on the other, here seems fine.

@dunx Hmm, DDEV is involved again. But is that not a vanilla installation? You weren't updating Drupal versions? So you did the first steps in the 'steps to reproduce' but not the step of updating? If so that could point to a different source of the error.

Nope, brand new installation following the instructions at that URL to "Try it out locally". Fresh install in a brand new folder, no upgrade or updates. Exactly the same error though character for character. I just Googled the error and ended up here. Happy to raise as a new issue, but it's a D11 issue, just a Drupal CMS D11 issue.

I did try RC1 a few weeks or so ago via a zip (provided by my colleague the_g_bomb) and that installed fine on the same machine. I'm regularly installing D10 Umami to create demos, so I don't think it's my setup. Perhaps I'll try a native D11.1 tomorrow and see what that gives me. I'd try and dig deeper, but it's been a while since I did any serious dev :/

I hope this is useful! Tell me if it's not. I tried to install D-CMS RC2 again with the same error.
I installed D11.1 using the following and it launched fine.

1. mkdir d11.1
2. cd d11.1
3. ddev config --project-type=drupal --php-version=8.3 --docroot=web
4. ddev start
5. ddev composer create drupal/recommended-project:^11
6. ddev composer require drush/drush
7. ddev drush site:install --account-name=admin --account-pass=admin -y
8. ddev launch $(ddev drush uli)

I might dig in to the launch-drupal-cms.sh and see if I can spot anything obvious.

@dunx Thank you for the details on your attempts to reproduce the issue. I followed your steps to reproduce in #53 and #55. That is, I followed the steps at https://new.drupal.org/drupal-cms/release-candidate. Running the launch script did not work for me. I had to examine the script and change --project-type=drupal11 to --project-type=drupal

Then the install worked and I could not reproduce the error.

However after reading the related issue https://www.drupal.org/project/drupal/issues/3457863 I checked out the 'set to default' themes in the site. Both the admin and the normal themes are child themes eg the admin theme has claro as its parent. Reading through issue 3457863 eg #18 by @pdureau it seems that that issue fixed the handling of parent-child themes.

Given this is a 'major' bug it is worth reaching out on Slack to those involved in the related issue. It may be a case of improving the test coverage in 3457863 so it covers edge cases. And improving the handling of related themes.

@dries From #47 I note you use claro for admin theme of your site. And a theme 'dries'. Is 'dries' a child theme? If so, what is the parent theme?

@oily... confirmed, changing --project-type=drupal11 to --project-type=drupal also worked for me, but that site is not being launched as a Drupal CMS site. I don't get the lovely new UI to choose recipes, etc, which I've previously seen in RTC1 and various demos. It just launches me in to what looks like a standard D11 website, albeit with missing images.

I did check the Status report page to confirm version - D11.1.0. I'm not sure whether Drupal CMS reports the version any differently or has anything that identifies it as "Drupal CMS" rather than "Drupal Core".

((Status report does list one error for updb, but I get a 404 clicking on the link https://drupal-cms.ddev.site/update.php and Continue for https://drupal-cms.ddev.site/update.php/selection - this certainly seems beyond the scope of this issue though.))

This is my themes config. It certainly seems to think it should by "Drupal CMS", but it's behaving like Core.

@dunx Thank you for the details. I am not sure who maintains the code for drupal-cms if its Acquia or Drupal.org. But either way the apparent bugs would surely interest the maintainers.

I did not see anything wrong with the front-end but then I did not experience RC1. The 'Olivero for Drupal CMS' is a child of the Olivero theme. You have to look in the theme .info.yml file to find it out.

It is a little unclear but it looks like you used drush updb. Do you recall whether the error message in the issue summary occurred after you ran that command?

Re-reading the change from [##3457863] it seems like something that used to silently fail before now fails loudly. Can't really see how that issue would have introduced a bug as such.

I think we should commit a quick fix to go back to silent (or logged) failure here, but it would be good to understand how sites are running into this issue in the first place.

Looking at #3457863: YAML discovery does not take theme inheritance into account I don't think we should be logging here. I think this is too low level place to log - we've benefitted from this code prior to #3457863: YAML discovery does not take theme inheritance into account dealing with this situation and I think we should continue to. There definitely should be a decent comment as to what is happening here.

Re #58: dries it not a child theme. I'm also not using Drupal CMS. I got the error before running drush updatedb, but I'm not sure that is related.

Based on recent experience of the WSOD message in the issue summary, these are steps to reproduce:

1. Install Drupal 11.0.x using the standard profile.
2. Use the composer 'drupal/core-recommended' version of drupal
3. If using DDEV, follow the DDEV quickstart for Drupal 11 but specify version 11.0.x
4. Navigate inside the admin theme (logged in as admin) and also logged out
5. Update Drupal to 11.1.x. by following the steps in the drupal composer update documentation
6. Navigate inside the admin theme (logged in as admin) and also logged out. See if the error appears.
7. Update the database using drush updb
8. Navigate inside the admin theme (logged in as admin) and logged out.

Don't want to muddy the waters so...
(("It is a little unclear but it looks like you used drush updb. Do you recall whether the error message in the issue summary occurred after you ran that command?" No it wasn't drush, just the UI link from the Status menu.))

I tried to reproduce as in #65 without success. I agree with #63.

I've changed the MR to be the bare minimum change here with no logging and a test for the capability of \Drupal\Core\Extension\ThemeHandler::listInfo() to ignore missing themes.

I think we should merge this ASAP to stop the hard to recover from problem.

That said if someone does encounter the issue if they can post the full backtrace of the error that would be super helpful as it would be great to know what code is listing themes as that might allow us to work out how the theme list does not contain all the correct information.

Yes this looks good. We should open a follow-up to consider adding the logging - clearly something is wrong even if it's very widespread.

Improved issue summary.

@catch I'm not sure about something being wrong - I think we might be in a situation where a later cache clear or invalidation results in this being fixed during an update. What we really need is actual steps to reproduce and a complete backtrace to see when this is happening. FWIW the fact that ThemeHandler::listInfo() is also responsible for calling ThemeHandler::addInfo() is really quite odd!

Updating credits

Committed to 11.1.x and backported to 11.x

Can someone open a follow-up to try and capture the exact stack trace and adding the logging?

Setting as NR until then. Please move to fixed once we have the follow-up.

Also backported to 10.4.x and 10.5.x after discussing with @alexpott

Will wait for an RM opinion as to whether this should also go to 11.0 and 10.3 that are security only now.

@longwave gave a +1 for 10.3/11.0 backport so did that too

FYI. A similar error also happened to my website and in Drush. Fortunately, I was able to correct the Drush error which also corrected the corresponding website error. Hope the link helps.

LinkToError

@othdvlpr Read with interest. It could help if you were able to give an exact set of steps to reproduce. So that any/ all the contributors here were able to follow and reproduce the error. You would need to give a link to the theme involved and to the same version, for example.

Otherwise you may have to wait for the a fix resulting from this issue and see if it fixes your issue?

I don't remember the exact set of steps, but I can relate what I was doing in more detail.
1. Attempted upgrade several times from 10.4 using the Drupal 11.1 install page. commands:

composer update "drupal/core-*" --with-all-dependencies
and
composer require drupal/core-recommended:11.1.0 drupal/core-composer-scaffold:11.1.0 drupal/core-project-message:11.1.0 --update-with-all-dependencies

neither of which were successful and gave varying errors such as the one in the DrupalUpgrade11Probs attachment.

2. One of my cleanup attempts must have included removing the
Insha theme, which was installed but not my default theme, Bartik.

I used the composer remove command to do this. Composer either denies the existence of objects or
displays choices such as:
sudo composer require symfony_mailer_lite
Pick one of these or leave empty to abort:
[0] drupal/symfony_mailer_lite
[1] drupal/swiftmailer
[2] drupal/htmlmail

3. After several attempts the theme errors in my site and drush appeared. After several failed attempts, I reinstalled the insha theme using the composer require command, as stated in item 3 of my error report. I then used the drush updb command successfully to reinstall additional modules required by drush updb, as in item 4 of my error report.

4. If I had to guess a possible cause of my error, it could possibly have something to do with removing an installed theme, even though it is not the default.

@othdvlpr Thank you for the details which may be of help to others here. But it is not clearly reproducible. To get others to try I suspect that you will need to do a clean install of 10.4 eg using DDEV and the drupal quickstart. Then copy from your command line history each command. Something like that. You would need to be able to reproduce it reliably yourself, first.

For the 10.3 backport

The backport to 10.3.x is already done, this is only open for opening the follow-up now.

Removing the "Drupal CMS dependency critical" tag, as that is for dependencies that we will rip out if the bug fix doesn't land. We can't very well remove core from our dependencies. :)

Forgot to remove the tag.

I opened #3497286: Fatal error: Uncaught TypeError: Drupal\Core\Extension\ThemeHandler::addTheme() if that's what was needed?

This was already committed, and the follow up made. I am removing the tag. I also made a few tweaks to the followup.

I am closing as fixed now.

As per #92

For me this was an issue of running a multi-site install with ddev, and I had to move the settings.php and settings.ddev.php files out of the default sites folder and into the correct custom sites folder. The system just couldn't locate my site's custom theme, which was also in that directory. I guess DDEV created it's settings file in the default directory.

Dries' comment #47 helped me figure this out.