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

  1. Clean local core test site running latest 11.3.x.
  2. Install https://www.drupal.org/project/login_disable/releases/2.1.2
  3. Visit /admin/reports/updates, see that you're missing a security update
  4. Visit /admin, see big scary warning about missing a security update
  5. Visit /admin/modules/uninstall to try to uninstall the insecure thing
  6. Still see scary warning message.
  7. 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

  1. Evaluate if any Project Browser or Automatic Update paths should also be exempted.
  2. Evaluate if the modules overview page should be exempted.
    No. That's one of the primary pages for why we added the hook_page_top stuff in the first place. In fact, there's code for a more detailed / verbose report on system.modules_list (and system.themes_page).

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3567589

Command icon 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

cmlara created an issue. See original summary.

dww made their first commit to this issue’s fork.

dww’s picture

Status: Active » Needs review

Totally 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() for system.modules_uninstall (and system.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 main branch for the MR, but that's still not quite working, so I'm sticking with 11.x for now.

dww’s picture

Issue summary: View changes

Re:

Evaluate if the modules overview page should be exempted

I vote no. That's one of the primary pages for why we added the hook_page_top stuff in the first place. In fact, there's code for a more detailed / verbose report on system.modules_list (and system.themes_page):

        // If we are on the appearance or modules list, display a detailed
        // report of the update status.
        case 'system.themes_page':
        case 'system.modules_list':
          $verbose = TRUE;
          break;

Crossing that off from remaining tasks.

andypost’s picture

IMO that's wrong solution as all existing sites getting this fatal error, IMO release name should be changed instead to dev-main at least in composer as even live sites started to fail and it will cause owners to disable update module - security--

cmlara’s picture

I vote no. That's one of the primary pages for why we added the hook_page_top

Devils advocate:
How does an inexperienced site owner navigate from login to /admin/modules/uninstall without 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).

andypost’s picture

cmlara’s picture

@andypost: Help topics were also taken offline by the WSOD.

dww’s picture

To 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.

dww’s picture

Re #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.

cmlara’s picture

Hopefully you’ve got toolbar or navigation enabled.

Using 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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

Recommended way to test this one?

dww’s picture

Issue summary: View changes

Re: #14: Added steps to reproduce to the summary. Hopefully that's clear and works for you.

smustgrave’s picture

Status: Needs review » Needs work

Sorry 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.

dww’s picture

Status: Needs work » Needs review

Changed MR target, rebased. Pipeline is running. Hope it's green. If not, someone else will have to restart it. 😅

Thanks!
-Derek

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative
StatusFileSize
new181.74 KB

following 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

error

Applying the MR I don't get the message

seems to work as advertised

  • godotislate committed d867a4ad on main
    chore: #3567589 Exempt 'system.modules_uninstall' route in UpdateHooks::...

  • godotislate committed e644f952 on 11.x
    chore: #3567589 Exempt 'system.modules_uninstall' route in UpdateHooks::...

  • godotislate committed b1608d10 on 11.3.x
    chore: #3567589 Exempt 'system.modules_uninstall' route in UpdateHooks::...
godotislate’s picture

Version: main » 11.3.x-dev
Status: Reviewed & tested by the community » Fixed

Committed d867a4a and pushed to main, committed e644f95 and pushed to 11.x, and committed b1608d1 and pushed to 11.3.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

dww’s picture

Sweet, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.