Problem/Motivation

It is sometimes hard to find a module in the code base:

  • Modules may be organized in (nested) folders
  • Module machine name does not necessarily match its readable name
  • There are different places (core/modules, profiles/.../modules, modules) where Drupal is looking for modules

Proposed resolution

Display module location in expandable detailed information section, together with machine name and version

Remaining tasks

Agree if this solution should be part of core, or moved to contrib (see comments #45, #49)

User interface changes

New line in detailed module information section

API changes

No API changes

Data model changes

No data model changes

Original report by @mlncn:

Use case: You just installed contrib module img_assist, nat, or i18n and are therefor most familiar with it by the name you just saw on the file when you downloaded it (or installed it with Drush).

You go to your modules page to enable this module for the first time, and faced with the huge list of modules, you fall back on ctrl+F to search for what you were just dealing with. There's a chance you won't find it because only the human-readable name for the module can differ a bit from the file name: Image assist, Node auto title, and Internationalization in this example, but contrib can get even more cryptic.

That's the basic use case but the point is that most people who will be using the module administration page will be handling the module files themselves at some point, one way or another. We shouldn't be hiding the module's system name for the sake of a slightly simpler interface.

A good spot for the system name would be right before or above the version number.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

galapas’s picture

Attached, find two patches.

The first (system-admin-inc.193034.patch) satisfies the request raised with this issue as it renames the module 'Name' column to 'Module Name', and adds a new column called 'System Name'. Further, 'System Name' is populated using the path of the module.

As feared, this solution does clutter the system module list, therefore I am including an alternative patch (system-admin-inc.193034-alt.patch) that leaves the columns as they were, however, hovering your mouse over the module 'Name' causes the module path to appear in a pop-up.

The alternative patch has the advantage of not adding clutter to the system modules page, though it does have the disadvantage not being searchable.

Note that the alternative patch is complemented by an update to system.module (system-module.193034-alt.patch) to provide help that reveals the otherwise hidden feature.

catch’s picture

Status: Active » Needs review
mlncn’s picture

These patches all work. Thanks galapas! If people like what they do, they're ready to be committed.

I'm still holding out for, somewhere -- maybe right before or right after the description, so most of the time we wouldn't even be taking up any more space on the page, vertically or horizontally, having just the system name (without the path). The path, which now that I've seen it on the modules page thanks to galapas' patch, is awesome to have but could be a pop-up, since there's not really any call to be able to search for it.

I tried to make a patch that did this, just a variation of galapas', but I screwed it up somehow. I'll try again in a day, several deadlines to make first.

galapas’s picture

Please note that the alternative patch (files system-admin-inc.193034-alt.patch and system-module.193034-alt.patch) do provide the pop-up already.

To be clear, the initial patch (file system-admin-inc.193034.patch) adds a 'System Name' column.

And the "*-alt.patch files provide the solution as a pop-up.

mlncn’s picture

Yes– and I think the best solution is the system name (without path) somewhere where it takes the least room, with the path as a pop-up ;-)

Pasqualle’s picture

Status: Needs review » Needs work

I agree with showing the help link only on admin/build/modules page. see: http://drupal.org/node/192962

So please move the module system name to the help page. It is as good as the tooltip solution.

Pasqualle’s picture

Status: Needs work » Needs review

but accept other reviews. did not mean to change the status

Robin Monks’s picture

Version: 6.x-dev » 7.x-dev
Category: bug » feature

Sounds more like a feature request to me.

Robin

dmitrig01’s picture

Title: Useability: module system names should be on admin/build/modules, as well as UI names » Usability: module system names should be on admin/build/modules, as well as UI names

I don't like this. It's not useful. It makes the UI confusing.

Sutharsan’s picture

Component: system.module » usability

Moving all usability issues to Drupal - component usability.

cburschka’s picture

+1, I not only love this, I need this. System names of modules are very hard to find out without opening a shell, and finding out where the module is (the equivalent of "which" in Unix) is impossible without doing so - and looking at {system} if the module is installed in multiple places.

If four columns are too much clutter, consider removing the version column, which is only useful if you are neither using update status nor CVS to keep your modules updated.

Bojhan’s picture

Please provide screenshot.

Pancho’s picture

One year after the last patch, the code has completely changed. I therefore rewrote the following variants:

  1. Adding a separate column for the module's filename
  2. Using a combined column for both the module's filename and the version
  3. Using a combined column for both the module's filename and the version + adding a hover with the complete path of the module

Enclosed are 3 patches and 3 screenshots (including 'as-is' but not the hover version).
Now this is really CNR...

mlncn’s picture

Status: Needs review » Reviewed & tested by the community

Fantastic, Pancho. Combined hover is awesome! I think it would be even better with the .module part of the module name removed (since this will always be there, it's not adding information), but even with that I'd call combined-hover.patch ready to be committed.

benjamin, Agaric Design Collective

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

catch’s picture

Status: Needs work » Needs review

re-testing.

Dries’s picture

I prefer the combined view as well. I wonder if we should also use the small font size for the combined column? No real preference, just floating the idea.

Magnity’s picture

+1 for combined column.

Smaller font seems like a good idea too - after all, if its mainly there for search purposes then it doesn't have to be too big - and small means the page doesn't get quite as cluttered.

However i'm not sure we need the hover function if the system name is visible anyway though.

mlncn’s picture

Hover gives the path. Not needed for search, but a big bonus in letting you know exactly what module is in use (a module could be located in profiles/example/modules, sites/default/modules/, or sites/all/modules for instance).

Bojhan’s picture

I am kind of disturbed by this patch, it seems to add a lot of clutter to a interface that is already very hard to scan trough. Calling for a smaller font basicly means, we want to make it less prominent (which I dont think is achieved by a smaller font). I see the case for people who have trouble finding the module, but does the occurrence of this problem weight up against the valuable screen real estate it takes up?

mlncn’s picture

The occurrence of the problem is frequent for anyone who builds or maintains a Drupal sites with many modules. Modules file names (which are your main reference for the module in the Drupal.org project path and when you download or use Drush) are equivalent to the system names, so it is key that they appear, and be searchable, on the listing page. Over the version works very well (echoing the tar file packaging) and makes good use of space.

Here's a small tweak to remove the ".module" file extension from the display. (Using substr– there's probably a better way, but at least you can see it, slightly de-cluttered.)

benjamin, Agaric Design Collective

Bojhan’s picture

Can you please supply a screenshot with your change? I still think that this patch would add to much clutter, isn't there a better way to solve this problem (at its occurance, the naming in CVS?)

The problem only exists, when you install a module that has a conflicting map name versus actual module name. Where we would like to use this page for more purposes, and making it a easier starting point to set permissions and configure your module propperly (illustrated here : http://groups.drupal.org/node/10919#comment-38637 ) however if we add system names to this page, we have to carefully rethink for who and if we still can balance this page.

Can't we put more emphasis on the modules, that have just been uploaded?

Status: Needs review » Needs work

The last submitted patch failed testing.

tstoeckler’s picture

Title: Usability: module system names should be on admin/build/modules, as well as UI names » Module system names should be on admin/build/modules, as well as UI names
Component: usability » system.module
Issue tags: +Usability
Jon Pugh’s picture

FileSize
2.35 KB
92.15 KB

Here's a patch that does three things:

  1. Adds the module key to the version so you get "blog-7.0-dev"
  2. Moves the version column over to the right
  3. Makes the font smaller and lighter in color, and aligns right... Should I align the table header right too? looks a little of balance

I like this because it unclutters the module name and description, AND gives me the full package name, so I think it solves both problems described here.

I also just think it looks better. The specific version information isn't all that helpful except in specific situations. This makes just browsing and visually searching the modules page easier on my eyes.

catch’s picture

Screenshot looks good to me - would make it actually possible to find modules using CTRL-F in firefox instead of getting lost in the dependency sea. Patch needs some whitespace fixes though. Also I think it's probably OK too leave the $version variable rather than using $extra.

Bojhan’s picture

I am still convinced that this patch adds a lot of clutter (making it gray, doesn't account for the 100 words + column more on this page), especially concerning all of the new ideas that are for this page that might be more in line with the workflow - we should really find a way to fix this without this method.

Jon Pugh’s picture

Yeah, I wasn't sure about the $module['version'] variable... I added it to $extra because the $module array comes direct from module_rebuild_cache. I didn't want to mess with the $module['version'] var in case it was used somewhere else.

re: #27, I do understand that the modules page needs a total overhaul, I just thought this small modification would help start that.

Magnity’s picture

I like this idea best out of the ones proposed so far. Mainly because it doesn't add another column, and only mimimal text. Its definitely a step up from the current ui, even if there could be a better alternative still.

mlncn’s picture

@Magnity - This does add another column-- I still think this system name can:

1. appear under the name (small and gray, careernerd's look in that respect is fine by me)
2. have the system path in a title tool-tip on hover-over!

@Bojhan - this provides lots of information and usability with almost no extra space and minimal clutter. Usability win. (I also agree that core should have a page of recently added modules featuring configuration links, but that should be a separate issue.)

Jon Pugh’s picture

First off, it doesn't add a column it just moves it.

Secondly, I think this page could use a multitude of enhancements.

Some information I think we should add:

  1. Multiple modules found: If there are multiple modules found in various directories, it should at the very least indicate that, and show which copy of the module is being used.
  2. Update status: If there is an update available it should show that here.
  3. Link to project page: There should be a link to the drupal.org/project page.
  4. Module Search: If the right Jquery is used, we could add an AHAH search to quickly filter the list down to what we're looking for. If this method is used, we could hide the version info altogether if we coded it to search that too. Note: I do understand that if we do this, we should provide the proper non-JS fallback code.

Of course, adding all of this extra information would clutter up the form. We should try to keep this page as simple and clean as possible if we are say we believe in making things easy for novices.

This issue is probably best merged with #363319: Redesign module page ...

I think any more work on this should be part of work towards a total redesign of the modules page.

Jon Pugh’s picture

Added a screenshot of a mockup for a total overhaul of the modules page... on this ticket: #363319: Redesign module page

I think we should close this ticket and move all discussion to that ticket.

mlncn’s picture

Let's keep this issue for now. This is a small, focused usability win, whereas the other issue is a very big change.

mlncn’s picture

Version: 7.x-dev » 8.x-dev

This is D8 now. I still really, really, really want this and think most people who use the modules page are 60% of the time enabling a module after getting it via a download or drush (and so see the project name in both cases) would really benefit from ctrl f here.

Adding system name search to module_filter module and trying to find a good way to put this in contrib are my D7 priorities.

Finding someone to hold Bojhan down while this gets committed is my D8 priority ;-)

mlncn’s picture

And, last mention until D8 dev begins... as a general principal, i don't think we should veto small wins on the basis that a much bigger win is necessary. That said, the disparity between the *projects* on the admin/reports/updates page versus the *modules* on admin/modules makes me think that lacking the project name, rather than the module system name, is the key usability issue. So enforcing grouping by project (the lowercase end of the d.o/project/namehere path, not any fickle changeable title), and turning package into a tagging/sorting option is a better fix...

Bojhan’s picture

Anyway, I am not convinced this is necessary for a majority of our users and even only for a small subset - even webchick and merlinofchoas said it probably won't be above 10%. Polluting the module functionality screen with stuff that will be useful only occasionally, to me sounds silly - since it will have a big impact visually adding another element. I am not saying we shouldn't do small improvements, because there are larger fundamental issues - but I am saying, we should aim for a solution that has little to no impact visually - using a title attribute could work for example.

You can hold me down, but this is not a matter of opinion - its a a UX argument and you are not considering it.

valthebald’s picture

Title: Module system names should be on admin/build/modules, as well as UI names » Display module system names and location on admin modules screen
Status: Needs work » Needs review
FileSize
8.76 KB
2.23 KB

I hope that in the current module list outline (with expanding description) adding internal module won't add much of a clutter, but provide information that would be useful for many. I even suggest going further and provide module location, not only internal name. Here's how it looks like after the patch:

module-location.png

TravisCarden’s picture

Patch works great, @valthebald; it just has a little extraneous whitespace. Here's the same thing with that cleaned. Hopefully with a few more reviews this can be RTBC-ed, because it's super useful and practically free.

Pancho’s picture

Title: Display module system names and location on admin modules screen » Display module system names (and maybe location) on admin modules screen

I'm not sure about #37/#38.
It is true that we have enough space after the redesign, but still it's not for free.
Extraneous information about internals does contribute to making things "feel complicated". Extending the Drupal install finally should be Plug'n'Play. We're not there, but if we now keep adding more technical infos, it's not getting better for the regular admin.

I like Jons idea in #25, which seems a good compromise, so we'd have a line such as:
Version: og_ui 8.0-2.4
It's quite some help even for developers, while not cluttering the information for the others.
It might be even better to make it link to the project or even to the release. Having project documentation and release notes at hands would be both intuitive and a lot more helpful for the non-developing admin.
And I think this would be the maximum we can still get into d8 after feature freeze.

In D9 and/or contrib we can later discuss 'verbose' modes and/or whatever else developers need.

TravisCarden’s picture

I think that the module location is important information. Suppose the case of a multi-site installation where the module could be in numerous different places—there may even be multiple versions of it in different directories. Such is the sort of case that motivated me to pursue this functionality, which a mere machine name does not address. Admittedly it's of less value to highly experienced developers, who'll probably use Drush to find such information. But this would be really helpful for newbies and folks who don't have access to Drush.

Pancho’s picture

@Travis:
I absolutely agree that the module's location is important, and there are situations where it would be very convenient to have it displayed just there. However, people like you and me and most developers know how to find stuff. We don't need "nodes" be called "content" or whatever.
Now what I was talking about, is how easy Drupal feels for the average guy installing it the first time, checking out some modules, making the first steps in building a simple site.
And what you're talking about, is how convenient Drupal is for intermediate admins and newbie developers.
That's two different audiences, and for both there are good arguments.
I'd argue that core should cater to the absolute Drupal noobs, because that's the area where we lag behind other CMS. Newbie developers can be catered by an additional contrib module.
Maybe we can even find a good solution for both. But first of all it would be important to know to which extent this can be improved in the D8 schedule.

valthebald’s picture

#41: Let's not underestimate novice Drupal users/admins. If they were able to download/unpack/install Drupal, would they be confused by paths to module file?

Pancho’s picture

How about this patch?
I'm providing both systemname and location, but exposing only the systemname, while enabling devel module to expose the location as well.
Also enclosed a patch for devel.module which does the rest. Use together.
This solution should cater about everyone while keeping things simple and clean.

valthebald’s picture

Issue tags: +Needs usability review

I think we're a little bit stuck between 2 options:

  1. Current issue's patch adds both system name and file path (patch #38)
  2. Current issue's patch adds system name, new issue is open in devel issue queue, patch from #43 is split between 2 issues

I personally don't think that module system name and file path create more confusion for novice site admins, than module system name alone, but it would be great to know someone from "UX squad"

Bojhan’s picture

Issue tags: -Needs usability review

I have already provided feedback in #22, #27, #36. I do not see this as necessary information, for the ordinary site builder. It sounds like this would be a fine contrib module, this would have been more important when the modules folder was still in the root of the Drupal download, but its not anymore - so the only usecases I see are 1) multi-site setups 2) you can't find the module folder corresponding with the module name.

For usecase 1), multi-site setups we already made that "upon adjusting settings.php" this kind of arguments the idea, that from a core perspective we consider this usecase small. So far my comments, have not even been discussed - so stop calling upon the UX team when you don't discuss their feedback anyways. The best step forward here is to get committers feedback, because the feedback you are getting is being ignored.

valthebald’s picture

@Bojhan: I was under impression, that changes in module list display made #22 and #27 less relevant (there is no additional clutter in module list anymore, at least in default state without expanding description block). Adding text in expandable block, IMO, falls nicely into "little to no impact visually" niche mentioned in #36.
I wouldn't submit patch in #37 without mentioned changes in module list display.
Regarding use cases that you see, it's 2) that seems to me more painful, having nested project folders (data/data_entity? Or, even less obvious, ctools/page_manager?)
Thanks for your feedback anyways

Pancho’s picture

Issue tags: +Needs usability review

[edit:]
@Bojhan: As valdebald says, your feedback in #22, #27 and #36 refers to the situation before the module page redesign and to particular outdated patches. So a new usability review would indeed be helpful now that we're talking about adding a row to an collapsed fieldset.
Also t

There is a large number of both contrib and core modules where the displayed module name differs from the module name in the filesystem, see "Interface Translation" vs. locale.module
Now if we say, we don't want to cater the 10% use cases of admins that do stuff in the filesystem (such as applying patches or modifying minor stuff), then it's fine with me. devel module can cater them adding some more information.

But the sheer internal name of the module is important to know even for admins that never touched any code. Whatever information they can get about say locale module on the d.o site or somewhere else will refer to 'locale module', not to 'Interface Translation'. So it's not just a matter of 'finding the module in the filesystem', it's a matter of 'knowing what you have enabled' and 'finding information about it in the net'. And that is a usecase 3) which is relevant for about every site admin.

That's why I think my patch in #43 is a slick solution for core and a nice enabler for devel.
However I'd be fine with either solution.
If we'd go for #38, we should remove the 'if ($version || $location || $requires || $required_by)' check, because every module has a $location.

Pancho’s picture

Sorry.

Bojhan’s picture

Issue tags: -Needs usability review +Needs committer feedback

@Pancho The fact that we have a disclosure method, does not mean its a good idea to put more stuff in there - we really tried to keep introducing all these features out of the module page issue, simply because it adds so much more clutter, progressively disclosed or not. I am not convinced that this is a prominent usecase, given that core should support prominent use cases - I don't think this should be part of core. I am sure there are usecases, and locale is one - but exposing this still adds clutter to an interface we purposely tried to keep really clean because its easy to feel overwhelming for beginners and intermediates.

However as said, I think this needs committer feedback.

Pancho’s picture

That's fine with me.
I'm adding a third, combined option as prefered by Dries in #17 (pre-redesign, though).

And I'm providing screenshots for all of #38, #43 and #50, so everybody has an immediate idea of what the patches are doing:

Screenshot with patch #38:
Screenshot with patch #38

Screenshot with patch #43:
Screenshot with patch #43

Screenshot with patch #50:
Screenshot with patch #50

No matter which version we're going for, I believe the search function should bring up both display names and module names, so a search for "locale" brings up "Interface Translation".
This would be a very helpful followup improvement, but requires displaying the module name in the fieldset, because otherwise it would be rather obscure.

Status: Needs review » Needs work

The last submitted patch, 50: core-module-systemnames-193034-50.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Issue summary: View changes
Issue tags: -Needs committer feedback +Needs issue summary update

What and what kind of committer feedback does this need? Product manager review?

Bojhan’s picture

We need a decision, don't think its really a product level decision.

valthebald’s picture

Version: 8.2.x-dev » 8.3.x-dev
Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs issue summary update

The last submitted patch, 43: devel-module-systemnames-193034-43-do-not-test.patch, failed testing.

valthebald’s picture

Issue summary: View changes
Issue tags: +Needs committer feedback

@xjm - updated issue summary, added references to comments that asked for committers feedback

TravisCarden’s picture

Issue summary: View changes

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work

For the feedback and will need to be updated for 10.1

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.