Problem/Motivation
#3567483: Update manager crashing admin panel with uncaught exceptions parsing version strings caused site WSOD's, the temporary solution for site owners was to uninstall the update module, however corruption in the update module would prevent accessing /admin/modules/uninstall allowing uninstall only from Drush or direct database access.
While Drush and config management may be preferred methods to manage config, the push of Drupal as a base for Drupal CMS requires the assumption that no CLI access or advanced database access will be available to the site owner.
The underlying cause will likely be solved, and hopefully no future issues will occur however it is worth questioning if there should be a failsafe in place to allow site owners to remove the module in the future if necessary.
Steps to reproduce
- Clean local core test site running latest 11.3.x.
- Install https://www.drupal.org/project/login_disable/releases/2.1.2
- Visit /admin/reports/updates, see that you're missing a security update
- Visit /admin, see big scary warning about missing a security update
- Visit /admin/modules/uninstall to try to uninstall the insecure thing
- Still see scary warning message.
- Imagine that another bug in update.module was causing WSOD trying to generate that message, and try to figure out how to turn off update.module via the UI to get your site working again.
Proposed resolution
Exempt 'system.modules_uninstall' route in \Drupal\update\Hook\UpdateHooks::pageTop()
Alternative: Catch \Exemption in \Drupal\update\Hook\UpdateHooks::pageTop() to avoid full site breakage.
Alternative: Find another method to protect the module uninstall page from becoming inaccessible.
Remaining tasks
- Evaluate if any Project Browser or Automatic Update paths should also be exempted.
-
Evaluate if the modules overview page should be exempted.
No. That's one of the primary pages for why we added thehook_page_topstuff in the first place. In fact, there's code for a more detailed / verbose report onsystem.modules_list(andsystem.themes_page).
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Screenshot 2026-03-27 at 5.29.48 PM.png | 181.74 KB | smustgrave |
Issue fork drupal-3567589
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
dwwTotally agreed.
Needs subsystem maintainer review.I hated it when folks added that fragile parsing code without catching possible exceptions. But here we are.
Probably best for scope to just do 1 thing at a time, so let's start with early return in
pageTag()forsystem.modules_uninstall(andsystem.theme_uninstall).We should look for and if needed, open another issue about catching those exceptions at the right places instead of letting them WSOD a site. 😬
Thanks!
-Derek
p.s. I tried targeting the new
mainbranch for the MR, but that's still not quite working, so I'm sticking with 11.x for now.Comment #5
dwwRe:
I vote no. That's one of the primary pages for why we added the
hook_page_topstuff in the first place. In fact, there's code for a more detailed / verbose report onsystem.modules_list(andsystem.themes_page):Crossing that off from remaining tasks.
Comment #6
andypostIMO that's wrong solution as all existing sites getting this fatal error, IMO release name should be changed instead to
dev-mainat least in composer as even live sites started to fail and it will cause owners to disable update module - security--Comment #7
cmlaraDevils advocate:
How does an inexperienced site owner navigate from login to
/admin/modules/uninstallwithout already knowing the path exists (context: I had to check a lab deployment to remind myself exact path) or having to be taught to manually navigate to the path during a failure (easy for engineers and most site developers, however I’ve worked with my share of site owners who absolutely need point and click everything).Comment #8
andypost@cmlara for example from https://git.drupalcode.org/project/drupal/-/blob/11.3.x/core/modules/hel... and other help topics
Comment #9
cmlara@andypost: Help topics were also taken offline by the WSOD.
Comment #10
dwwTo be clear, this cannot help with the current situation. The immediate site crashing was quickly resolved at
#3567494: Filter main branch from the list of core releases
The fatal errors from blindly trusting the feed to always have valid versions will be resolved at
#3567483: Update manager crashing admin panel with uncaught exceptions parsing version strings
This issue has nothing to do with encouraging folks to disable update status. It’s to give non-CLI site admins a way to uninstall in case another similar bug brings down sites and they need to (temporarily) turn off update status to bring the site online at all.
Meanwhile, from a UX perspective, if you’re already in the act of trying to uninstall something from your site (perhaps because update status told you there’s a security problem or it was marked unsupported, etc), you probably don’t need to/ want to see more error messages about unsupported releases to distract you from the task you were already in the middle of. The same reason we skip other admin paths for this hook applies to this particular admin page. So this was an oversight from 20 years ago that we should have had all along, even if it’s not also a very useful failsafe in case of trouble.
Comment #11
dwwRe #7 I don’t see how that’s gonna help. If /admin itself is crashing, how are you gonna find /admin/extend or whatever? Hopefully you’ve got toolbar or navigation enabled. Hopefully those work enough to let you find it. Or you ask The Internet and Google/AI will tell you. But I don’t think we want less info about update status on one of the main pages where you need to be reminded about update status if you’re not already looking at the available updates report itself.
Comment #12
cmlaraUsing the stock theme that comes with Core as default, you can see the general modules page (2 levels deep) on the navigation menu not the uninstall page (3 levels deep) when browsing general pages with the admin toolbar would be the argument for why the main module page would need to be exempted.
You’re right that no toolbar and your out of luck completely.
Comment #14
smustgrave commentedRecommended way to test this one?
Comment #15
dwwRe: #14: Added steps to reproduce to the summary. Hopefully that's clear and works for you.
Comment #16
smustgrave commentedSorry just realized that the MR needs to be updated for main. Sorry for taking so long if this comes around again just ping me and I'll move to the top of my list @dww.
Comment #17
dwwChanged MR target, rebased. Pipeline is running. Hope it's green. If not, someone else will have to restart it. 😅
Thanks!
-Derek
Comment #18
smustgrave commentedfollowing the steps you provided.
I downloaded the zip https://www.drupal.org/project/login_disable/releases/2.1.2 since composer doesn't work
I did edit the .info file to include 12 so I could install
Applying the MR I don't get the message
seems to work as advertised
Comment #23
godotislateCommitted d867a4a and pushed to main, committed e644f95 and pushed to 11.x, and committed b1608d1 and pushed to 11.3.x. Thanks!
Comment #25
dwwSweet, thanks!