The attached patch modifies user.admin.inc so that it displays the human readable module names at admin/user/permissions instead of "[system_name] module".
| Comment | File | Size | Author |
|---|---|---|---|
| module_list_names_00.patch | 1.64 KB | xano |
The attached patch modifies user.admin.inc so that it displays the human readable module names at admin/user/permissions instead of "[system_name] module".
| Comment | File | Size | Author |
|---|---|---|---|
| module_list_names_00.patch | 1.64 KB | xano |
Comments
Comment #1
cburschkaWill there be an appreciable performance impact when parsing all the module info files?
Comment #2
dries commentedThis is the right thing to do from a user's point of view and that is what matters. Committed to CVS HEAD.
Comment #3
David_Rothstein commentedThis patch seems to have broken lots of links all over Drupal (most prominently, all the "Configure permissions" links at admin/by-module, which now no longer jump to the correct place on the permission page).
This is because it changed the "id" in the HTML to use the user-friendly name also... not the right behavior, IMHO.
Also, is it really necessary to parse every single module info file every time you want the human-readable name? It seems to me that the human-readable name is useful enough that it might make sense to just store it in the {system} table in the database, along with other stuff from the info file, and then it would be much more accessible. I guess that could be a separate patch, though.
Otherwise, it's good to see this go in!
Comment #4
David_Rothstein commentedAh, I just noticed that the human-readable name is already stored in the {system} database table ;)... it's hiding away in the serialized array in the "info" column.
So maybe it would be better to use the database to get this parameter, rather than parsing all the info files each time the page is loaded?
Comment #5
xanoI guess somebody rolled back this commit without telling it, because the user friendly names are no longer being used. I'll create a new patch using the method suggested in #3.
Comment #6
dave reidIt looks like it's still there, just probably not working correctly. See http://api.drupal.org/api/function/user_admin_perm/7
Comment #7
xanoSeems like it's being fixed somewhere else already.
Comment #8
xanoComment #10
xano