Add ThemeUninstallValidatorInterface similar to ModuleUninstallValidatorInterface

The absence of this is causing all config that depends on the theme to be deleted without warning! For module uninstallations causing config to be deleted, a detailed confirmation dialog is presented. The same should happen for theme uninstallations.

So SDC's are available at all times if a theme is enabled, even if it's not in the active theme context?

Conceptually this makes sense if someone wants to start working on an MR.

Could we rebrand it as ExtensionUninstallValidatorInterface?

@cilefen good idea, but I don't think we want to do that.

Module and theme uninstall are different enough I think we want to keep these separate.

I'm not 100% convinced myself so if you have further thoughts please share.

The absence of this is causing all config that depends on the theme to be deleted without warning!

Not really a normal feature request then, bumping to critical.

As far as I can see the request here doesn't need a ThemeUninstallValidatorInterface, as this isn't done via an uninstall validator for modules.

ModuleUninstallConfirmForm::buildForm() shows the dependent entities:

    // List the dependent entities.
    $this->addDependencyListsToForm($form, 'module', $this->modules, $this->configManager, $this->entityTypeManager);

There is no such confirmation page for uninstalling a theme - a theme can be uninstalled from /admin/appearance with just a CSRF token.

Which means this is probably a duplicate of #3096170: Add Confirmation Page for theme uninstall?

Aren't the validators about adding rules around uninstall? We need both right?

Well, we at least need the confirmation page first before we can even validate the uninstall I think? But module dependencies aren't handled through an uninstall validator anyway from what I saw.

Well, we at least need the confirmation page first before we can even validate the uninstall I think

Yes, I think that is accurate!

But module dependencies aren't handled through an uninstall validator anyway from what I saw

My understanding is that it's just for checking a condition that has to pass before moduleUninstall is allowed.
This is for things beyond just module dependencies. For example the field module has one to prevent it's uninstall if there are still fields pending deletion.

But is there any concrete use case for this for themes? So far I've only seen config dependencies requested, and the uninstall confirmation issue already handles that.

You're most likely right, I could see some distros wanting to do this to prevent uninstall entirely, but you can still change defaults.

We can leave this pmni for a bit for feedback and close it if the confirmation page works.

I think it's safe to close this, the confirmation page has been in for a couple of months and it provides a dialog about the config.