Add Confirmation Page for theme uninstall

Updated the IS with issue template and added steps to reproduce.

We already have \Drupal\Core\Config\Entity\ConfigDependencyDeleteFormTrait::addDependencyListsToForm. We need to add the confirm form step as per \Drupal\system\Form\ModulesUninstallForm::submitForm and \Drupal\system\Form\ModulesUninstallConfirmForm::buildForm.

Added a first pass, seems to work from rudimentary testing. Needs test coverage.

Came here via #3550019: Add ThemeUninstallValidatorInterface similar to ModuleUninstallValidatorInterface which appears to be requesting the same thing.

Cleaned up the form a bit and added some tests.

This feels like the extension api even if it's in the system module.

I'll try to review this.

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.

Appears to have a phpstan failures

 ------ ----------------------------------------------------------------------- 
  Line   core/lib/Drupal/Core/Entity/ContentEntityDeleteForm.php                
 ------ ----------------------------------------------------------------------- 
         Ignored error pattern #^Method                                         
         Drupal\\Core\\Entity\\ContentEntityDeleteForm\:\:addDependencyListsTo  
         Form\(\) has no return type specified\.$# (missingType.return) in      
         path /builds/core/lib/Drupal/Core/Entity/ContentEntityDeleteForm.php   
         was not matched in reported errors.                                    
 ------ ----------------------------------------------------------------------- 
 ------ ----------------------------------------------------------------------- 
  Line   core/lib/Drupal/Core/Entity/EntityDeleteForm.php                       
 ------ ----------------------------------------------------------------------- 
         Ignored error pattern #^Method                                         
         Drupal\\Core\\Entity\\EntityDeleteForm\:\:addDependencyListsToForm\(\  
         ) has no return type specified\.$# (missingType.return) in path        
         /builds/core/lib/Drupal/Core/Entity/EntityDeleteForm.php was not       
         matched in reported errors.                                            
 ------ ----------------------------------------------------------------------- 
 ------ ----------------------------------------------------------------------- 
  Line   core/modules/system/src/Form/ModulesUninstallConfirmForm.php           
 ------ ----------------------------------------------------------------------- 
         Ignored error pattern #^Method                                         
         Drupal\\system\\Form\\ModulesUninstallConfirmForm\:\:addDependencyLis  
         tsToForm\(\) has no return type specified\.$# (missingType.return) in  
         path                                                                   
         /builds/core/modules/system/src/Form/ModulesUninstallConfirmForm.php   
         was not matched in reported errors.                                    

Overall the direction looks great, I took a look through the code and it makes sense.

There are some relevant test failures though.

I think this is ready!

I think a parameter is fine, if we do want to change that to a path part we can do that in a follow up.

I think this feature is long, long overdue, I've accidentally uninstalled themes before!

I pulled this down and manually tested each case, a missing theme, no theme parameter, a base theme of an active theme, the current default, the current admin.

I wasn't sure at first why we needed all of the guards, since the uninstall link does not show up on themes you cannot uninstall,, but you can change the parameter, so it makes sense to guard against it.

I also looked at the module uninstall confirmation and this is consistent with that form.

Only took a quick look, and it looks like this is largely parallel to the module uninstall confirmation form, but do we need a usability review for this? Maybe at least screenshots for the changes?

Yes screenshots would be good, they'd be needed for a usability review anyway (but I think if it's consistent with module uninstall it'd be fine to go ahead without one here - we can always tackle them at the same time).

Attached are screenshots of the Theme and Module uninstall confirmation pages.

I'll post in the channel!

We discussed this issue at #3580386: Drupal Usability Meeting 2026-03-27. That issue will have a link to a recording of the meeting.

The attendees at the usability meeting were benjifisher, nicxvan, rkoller, simohell, the_g_bomb, and worldlinemine. I am giving them credit on this issue.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Some notes and recommendations from the meeting, thank you everyone for your feedback!

We should update the page title getQuestion to Uninstall <theme name> Theme

We should update the warning text to:
The <theme name> theme will be completely uninstalled from your site, and all data from this theme will be lost!

We need to create two follow ups:
1. For the module uninstall form to update the page title depending on if one or multiple modules are being uninstalled:
Uninstall Module
Uninstall Modules

A follow up for the SDC issue discussed in #3550019: Add ThemeUninstallValidatorInterface similar to ModuleUninstallValidatorInterface

Based on #32 and #33 updating tag.

Working on changing page title and warning text.

I've updated the page title and warning text. Updated Test to match the same. Attached is the screenshot of the updated confirmation page.

I think this is ready!

I updated the screenshots in the Issue Summary based on the new one you took.
I reviewed the new commits.

This is a UI change does it need a CR?

Edit: Asked in slack and both @godotislate and @smustgrave suggested we should, so I created one.

Took a pass at credit too.

@nicxvan, I’ve added a comment on the MR. To reiterate here, the buildForm() method is currently performing certain checks that would be more appropriately handled in the form validation layer.

@sivaji_ganesh_jojodae That's a confirmation form. There's no benefit to delay those checks if there's nothing you can confirm, so better redirect early. The MR is good as is.

Nice work, everyone! This is close, just a couple comments on the MR.

I've addressed the comments on the MR.

I don't think we want to change away from query parameters, I'm not sure why map query parameter did not work.

MapQueryParameter worked when I tried it locally. Maybe adding the use statement was missed?

Thanks for the quick feedback on this. Yes, it was the missing use statement. There was a comment suggesting to use menu parameters. Anyway it is reverted to query parameters now and test is passing.

Looks good now! Thanks!

Committed and pushed 392da0f to main and 7ef1790 to 11.x. Thanks!