Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In D7, there was a nice flow of:
- Enable a module
- Click on the module's configure/permission links, so you don't have to go "pogo-sticking" all over the admin UI to find where they are.
In D8, that's now obscured though because those handy links are buried in a collapsible section. I think for the most part that makes sense when I'm in "browse" mode, but when I've just enabled one or more modules, it'd be nice if the subsequent page refresh had those modules' sections auto-expanded by default so I could discover those links more easily. Since these links weren't there the first time I expanded the box to read the description, etc. before enabling it, I doubt that people would bother expanding the sections manually afterwards to know that something had changed.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | core-js-last_module_show-1851128-5.patch | 3.31 KB | nod_ |
Comments
Comment #1
sunI think this issue duplicates #407022: Show help and configuration links when modules are enabled. and related issues.
Comment #2
webchickHm. Don't think so? This is just fixing a very straight-forward UX regression that went in as a result of the new modules page. That other issue seems to be exploring various other ways of exposing this stuff.
We already have links directly to Help / Permissions / Configure in the details sections of each module; we simply need to expose it upon module enable so users can discover it.
Comment #3
sunYeah, what I forgot to say is that I don't like the idea ;-)
There's a closely related issue to the one mentioned in #1, #1168082: Module configuration links are easily missed after a module install, which already clarifies that there's an existing UX bug with the idea of the existing links.
I don't want to duplicate those issues here, but the main problem I see is that - even if those details were automatically opened - they are buried into a veeery long sea of modules that are grouped into isles, and no matter how hard you try to make those links "apparent", they will not be apparent — just simply because they are out of sight. :)
In addition to those two issues, I think there's a third one somewhere, for which we already committed a low-level API addition a long time ago, and which intended to expose the "Just Recently Enabled Modules" in a completely new + separate group at the top of the page.
Comment #4
webchickRight. And thats why I'd rather keep this issue separate, because this is just repairing a straight-up regression from D7's UX, and is probably a 2-line patch. And while we know that D7's UX isn't optimal, we don't have a clear path for fixing that yet. Instead, we have like 12 paths or something :), all of which are mentioned at the other issues.
Comment #5
nod_Patch that works. Uses sessionStorage so the enabled modules won't display after a browser restart. It's just for people to play around with. I made it depend on underscore since it's array/collection functions are really handy here. Some light renaming of variables in previous code as well.
It doesn't open dependencies, just the module the use clicked on. (to have dependencies also using something like #1473760: Use data-* to check modules dependencies before submit would make it possible without anymore PHP involved). Anyway, that was quick and dirty, and fun :p
Comment #6
Bojhan CreditAttribution: Bojhan commentedI think the propper fix to this is creating a category "new" and expanding those by default. I don't think it makes loads of sense to seemingly randomly open modules in the module list unless we give it some styling to indicate its new.
Comment #7
eigentor CreditAttribution: eigentor commentedGreat if we could get that grouping of new modules (probably at the top?) in this cycle. I second Bojhan that the new modules need to be grouped together to make visual sense. But should it be only the enabled ones? I am not so sure we get module browser in, so more important are the just uploaded modules that are not yet enabled, because those are the ones the user may have trouble to find. Which makes for two groups, ack...
How long is a module new? Or should that be another issue, not to derail this one.
Comment #8
klonosI really like the idea of having a "recently enabled" modules at the very top of the list because it seems very familiar to what I'm used with Mozilla products' addons. It would also help troubleshoot issues occurring after recent updates.
Instead of having these modules be expanded by default though, I propose introducing a show-links-on-hover feature (something in the spirit of the contextual links/cogwheel). This would not be available to the recently enabled modules only, but to all modules because I really hate how now in D8 I have to click to each and every module I want to setup in order to find their "configure" link - or sometimes to find out that they actually don't have one. So, I consider that a UX regression compared to how things worked in D7.
I haven't filed an issue for this suggestion because it'd be nice to get some feedback of how it sounds to others first. So, what do you think?
Comment #9
nod_The auto expand on enabling a module doesn't work very well (see patch up there). And the solution in #6 is very different than what we're talking about here.