New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[UX] Streamline the process of disabling and uninstalling modules (a.k.a. "Uninstallation queue"). #2532
Comments
...it would also be a nice bonus if we moved the dependencies confirmation when enabling modules to a dialog instead of the separate page the user gets redirected to after hitting the "Save configuration" button. |
Heh... you can disable Devel directly with B, but it won't disable the modules that depend on Devel. See backdrop-contrib/bee#24 for details. (Of course, that'll break the site.) |
I for one, would love to see a module uninstallation queue, but since we are only a single day from feature freeze and there's no PR for this issue, it's unlikely that it will make this release. Bumping milestone to 1.8. |
There's a great related conversation happening over at #541 |
Yup, saw that 👍. Commenting there now... |
Current process after one for example has enabled say
devel
anddevel_generate
:/admin/modules
/admin/modules/uninstall
/admin/modules/uninstall
, now "Devel" is unlocked/admin/modules/uninstall
OMG, finally!!! ...and this is only with one level of dependency. Imagine if you had a
devel_generate_extras
module installed that depended ondevel_generate
and you wanted to disabledevel
. That would makedevel_generate
be locked untildevel_generate_extras
was disabled/uninstalled and thendevel
would still be locked untildevel_generate
was disabled/uninstalled. O-M-G!!!How I envision this to work ideally:
/admin/modules
-> "Devel" is not locked/admin/modules/uninstall
that has a report of which modules were disabled and which were uninstalled, giving you the option to uninstall any that are just disabled.Compare 5 steps (no matter the complexity of dependencies) vs. at least 12 steps with one level of dependencies. Now, that's something I'd like so see fixed in the next minor release.
The text was updated successfully, but these errors were encountered: