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

This is probably related to 🐛 YAML discovery does not take theme inheritance into account Active .

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. Tell me how to reproduce it.

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

Can be checked with drush: drush cget core.extension

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.
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 as Drupal 8 releases for Admiminal don't appear to have this dependency.

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.

I can confirm that the patch worked and no new error was introduced. The only error that appears in relation to themes is

[error]   (Currently using Removed core themes You must add the following contributed themes and reload this page.
 * Stable [1]
 * Classy [2]

But this was there before the issue appeared in 10.3.6, so not sure how relevant it is.

Nonetheless the patched works.

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.

@trickfun I took the patch from the merge request in gitlab.

https://git.drupalcode.org/issue/drupal-3478628/-/commit/53479799d82fb27...

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.

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.

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 ?

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.

Since the pipeline is running all green, I believe the remaining tasks are

• Carry out a review by upgrading to Drupal 11.x as described in 'steps to reproduce ie manually test 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?

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 discovered DDEV relies on a particular composer drupal project. Seems you cannot use DDEV with the other major drupal composer project. However all the documentation for doing upgrades I found on drupal.org specify the other major drupal composer project.

I wanted to follow the upgrade steps documented on drupal.org but realised I would probably need to use another tool, perhaps docker4drupal.

So the 'steps to reproduce' will ideally specify the docker tool used and the drupal composer project and the steps taken to upgrade: these vary I think between the 2x drupal composer projects?..

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

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?

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 🐛 YAML discovery does not take theme inheritance into account Active 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 🐛 YAML discovery does not take theme inheritance into account Active 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 🐛 YAML discovery does not take theme inheritance into account Active 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.

larowlan → closed merge request !10272

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 🐛 Theme deletion causes ThemeHandler::addTheme() error Active

@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 🐛 Fatal error: Uncaught TypeError: Drupal\Core\Extension\ThemeHandler::addTheme() Active 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