Uninstalled custom theme stuck in config blocking config import

I noticed the $list array is only used for checking base/sub themes. So I moved the isset() check around. Attached is a patch without tests to see what (if anything) fails.

Is there any other way around this issue? I've been having it as well on a project I'm assigned to.

We would like to apply this patch if it is stable enough, or if anyone has other recommendations on fixes they would be much appreciated.

I was able to apply the patch in #4 and I was able to import my config again.

It seems everything works fine. Cannot guarantee there are any sideeffects.

I recently ran into this issue, running drush updb seemed to work for me.

It looks like patch #4 is already in core now.

Is it? It's at least not in 8.7.1. Here's a reroll.

Trying to fix tests (was removed catch of the exception from the test, because we don't use this exception in code anymore)

Next one

Here is a re-roll for 8.7.x version.

I ran into what sounds like a very similar issue. I solved it by recreating a directory and my_theme.info.yml for the offending no-longer existent theme in my dev site. I cleared the caches and went to the appearance page in the UI (/admin/appearance). There I uninstalled the offending theme and then exported the configuration. I then imported the configuration on my production site and the original errors complaining about the missing theme no longer appeared and the configuration imported successfully.

The latest patch was rerolled to version 8.9

Added fix for the latest patch

Sorry, it was a wrong file.
I hope this one will be much better

I can confirm patch in #25 fixed the issue for me.

Re-rolled patch up to 9.1

Here's a reroll against 8.9.x (applies to 8.9.6).

#29 Helped me in 8.9.13

This is still a problem for me as I cannot patch core because the site is part of a major university provided service.

Any way to get this reviewed and committed?

Could not apply patch #28 in 9.1.8

Rerolled the patch in #28, thanks!

#21 Worked for me simple and easy

Patch #35 worked for me in Drupal 9.2.5, thanks!

Initially I was going to add a comment saying we don’t support uninstalling themes without code because it’s the same as modules… and then I thought about it and I’m not sure that this is correct. Like theme’s don’t support hook_uninstall() so why shouldn’t we let them be uninstalled if they are not present. So maybe this is reasonable. I certainly think if we do this we need more documentation in \Drupal\Core\Extension\ThemeInstallerInterface::uninstall() and we need to update it because it is no longer throwing an \Drupal\Core\Extension\Exception\UnknownExtensionException exception. Plus we'll need a change record.

For the change record mentioned in #40.

Did not test patch.

Added a basic change record. Keeping this on needs work for the documentation.

Fixed remarks in #40

CR has been added, in addition to the added comments.

Manually ran the tests and all green.

Could this of been used between 9 and 10 to uninstall classy?

+++ b/core/lib/Drupal/Core/Extension/ThemeInstaller.php
@@ -266,9 +266,6 @@ public function uninstall(array $theme_list) {
-      if (!isset($list[$key])) {
-        throw new UnknownExtensionException("Unknown theme: $key.");
-      }

I think we should replace this with

      if ($extension_config->get("theme.$key") === NULL) {
        throw new UnknownExtensionException("Unknown theme: $key.");
      }

So we can only uninstall themes that are listed in the core.extension.

Otherwise this happens:

vendor/bin/drush thun blah                                                                                                                                                           
 [warning] The following theme is missing from the file system: blah ExtensionPathResolver.php:63
 [success] Successfully uninstalled theme: blah

Looks like the test coverage changes were also wrong, updated test + code based on #47.

Manually triggering tests and hiding old patches.

All green. And feedback from #47 has been addressed.

Committed and pushed bfc5c6d181c to 11.x and 01b19986028 to 10.2.x. Thanks!

Backported to 10.2.x as a non-disruptive bugfix.