[PP-3] Figure out what to do with the install/uninstall modules page

Created on 4 July 2013, over 11 years ago
Updated 5 September 2024, 3 months ago

Problem/Motivation

Post- #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed , the Modules UI looks like this:

Checkboxes are used in order to enable modules. However, once modules are enabled they can never be disabled, so the checkboxes stay checked and disabled, even for non-required modules and modules without sub-dependencies (unlike what the disabled checkboxes represented in Drupal 7).

The only thing you can do after enabling a module is uninstall it, but that's on a separate tab, which is not immediately obvious. The discussion here is how to address this disconnect, ideally by combining the two pages.

Proposed resolution

Several proposals have been put forth:

Option 1 : Move checkboxes to "bulk operations" style checkboxes, add drop-button for action, add column to indicate on/off status of modules

Mock:

Option 2 : Keep checkboxes as they are, make the "off" version perform uninstall

This is the simplest thing that could possibly work. It's tricky however, since "uninstall" is destructive, making it very easy for people to accidentally delete data they didn't mean to by making it "too" easy to perform uninstallation, especially if enabling/uninstalling modules are combined into the same form submission.

yoroy mocked a confirm form to warn people about potential destruction, in response:

Updated confirm form from Bojhan:

Option 3 : Stop using checkboxes for communicating state; switch to buttons instead

Possible mockup from Bojhan in #54 :

The advantage to this approach is that colour cues as well as labels can begin a warning prior to initiating any action. There is also no chance of weird interactions when trying to install and uninstall modules in the same page request. The disadvantage is installing multiple modules in one go is no longer possible (which is convenient esp. for modules like Drupal Commerce, etc. with multiple sub-modules), though presumably toggling would initiate an AJAX request so it wouldn't be quite as tedious (however, bear in mind that each button click is initiating a 30+ second page load by rebuilding all of the various caches).

This one has one other strong advantage which is that it is a very visually stark change from Drupal 7, which is indicative of the stark behavioural change from Drupal 7 as well, which will hopefully cut down on accidental destruction of data from those who do not read warnings carefully enough.

Option 4 : Add uninstall button to each enabled module

Similar to browser extension UIs, this would place the uninstall button on the same row as the enabled module, within the "expanded" view. This also has the advantages of being highly visible what you're about to do, and an incremental improvement. We would lose the feature of being able to uninstall many modules at once, but this could be a "feature" from a stability POV.

Option 5 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed : Make modules page similar to admin/content

Same style and pattern as with content and module specific actions as dropbuttons. Also including bulk actions and combining this list/layout with confirmation page from Option2.

Remaining tasks

Discuss, deliberate, make a decision.

User interface changes

Yes; that's rather the point. ;)

API changes

Unknown.

Original report by @fubhy

D.o procid experiment

This issue would be a good case study to evaluate procid #2154143: Evaluating Procid, a tool to help the drupal community improve the consensus building process for d.o issues
You do not have to use procid to work on this issue, but if you want to, your feedback would be very helpful.

----

Follow-up / spin-off for #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

Once #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed is in the install/uninstall modules page are going to need some serious overhaul and re-consideration regarding the UX. Let's discuss that here. We might end up with only one page too if we can figure out how to solve this in a way that does not end up with people accidentally uninstalling modules and thereby deleting all their data.

There are currently two WSCCI conversion issues for these two pages:

#1990544: Convert system_modules() to a Controller
#1993202: Convert system_modules_uninstall() to a Controller

Which did get a fair amount of love already. We might want to do a straight conversion first and then fix this issue afterwards after using those two issues basically as first iteration for a clean-up of the existing code.

This issue is critical as it's a required follow-up for the original issue which is also critical.

📌 Task
Status

Postponed

Version

11.0 🔥

Component
System 

Last updated 2 days ago

No maintainer
Created by

🇦🇹Austria fubhy

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • DrupalWTF

    Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024