One of the features of Earl's New module administration page with many new features that I felt most strongly about was the centralization of all module administration tasks in one common place. An excerpt from my comments here: http://drupal.org/node/76340#comment-127369 on the subject:
...when enabling a new module, there are no less than 3 places you have to check in order to configure it:
1. access control, to see if it added any permissions.
2. admin/something/something, to see if it added any administrative interface.
3. admin/settings/something, to see if it added any settings that need to be configured.And often times there are more. These don't apply to every module, but they apply to enough that you may want to check those too:
1. help, to view information about the module and how to use it.
2. content type settings, to see if the module added anything to the node settings form (I can't begin to count the number of "event module doesn't do anything!!" posts because of this).
3. other?And finally, there's "everything else", all the totally unpredictable paths that a module can add to the system. a lot of them are intuitive, but others are not... for example, tracker.module adds "recent posts" Others are not directly visible in the navigation menu (such as "blog" to view all blogs), and thus people might miss functionality.
Short of reading hook_menu, there really is no way for someone to know all the things a module does when they enable it, other than doing this click-through excercise.
Currently we're attempting to do this with the admin/help text. The problem is, admin/help text is "dumb"; user.module's help text doesn't know whether you have profile module enabled or not, when it tells you you can configure profile settings at administer >> user settings >> profile. And sure, the help text could be made smarter with dynamic bits, but you still have to click to different pages to find the links, and it's not standardized. While all core modules have help text, contrib modules are totally spotty. And it's much easier for a module developer to say, "these links should show up in a 'dashboard' panel" than it is to write help documentation.
I feel very strongly that this functionality needs to get into core for 5.0. I don't, however, think that .info files are the correct place for it. I'm thinking it would probably ideally be implemented as a hook, like hook_admin_links() (since it only needs to be run for enabled modules), and have a new admin menu like admin/dashboard. But since we're in a code freeze that can't happen.
Any insight anyone has would be appreciated. I'm very tempted to mark this as 'critical' but I don't want to ruffle any feathers...
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | admin-by-module_2.patch | 7.1 KB | chx |
| #14 | admin-by-module_1.patch | 7.26 KB | webchick |
| #13 | admin-by-module_0.patch | 7.05 KB | chx |
| #9 | admin-by-module.patch | 7.33 KB | Steven |
| #3 | dashboard-excerpt.png | 25.01 KB | webchick |
Comments
Comment #1
webchickA thought... what about adding an additional property to hook_menu items?
- 'admin_task' => TRUE
Then, the "manage your site" link could module_invoke_all('menu') and check for this property on each; if present, display the link in a list.
Then there wouldn't be any API changes, apart from an additional menu callback. Or, if even that is too grievous, we could put these links on the admin/settings/modules page as they were in Earl's patch. There was concern though that that page is already going to be too busy (esp. when dependencies get in), and should really only be for the enabling/disabling/uninstalling of modules, which I tend to agree with.
Comment #2
webchickHere's a patch that starts this process. It adds in a dashboard which shows all the links of a module (or will, if the patch ever gets done ;)).
API changes:
- Adds an 'admin task' property to menu items.
- Adds an 'admin title' property to menu items.
- One additional menu callback in system.module for the "dashboard" page.
- Theme function for said menu callback.
No work has been put into theming, etc. Just a "quick and dirty" patch to see how the idea is received. Screenshot coming up in a sec.
Comment #3
webchickComment #4
webchickActually, merlinofchaos had a much better idea on IRC: make this a separate tab of the admin/settings/modules screen. So we'd eventually end up with three tabs:
1. configure (the current admin/settings/modules screen)
2. administer (this one)
3. uninstall (when we get the uninstall stuff finished)
I don't have time to code that just now, but putting a note here so I don't forget. :)
Comment #5
merlinofchaos commentedI'm very much in favor of something like this as an adjunct to the modules page, perhaps as a tab. I'm not sure what to name the tab though; 'administer' is the best word but duplicates the main 'administer' link and might be kind of confusing, even though what you're really doing is a separate view.
Heh, then maybe we could go back to m3avrck's nice layout of the links, which was very attractive, and without the enable/disable/uninstall buttons there, we could have some more space.
Comment #6
Steven commentedAlternative idea... on /admin, have tabs "by task" and "by module" ?
Comment #7
webchickOh I like that even better!
Comment #8
webchickI asked Steven about this again and he pointed out it would be much better to derive the admin links programmatically (perhaps by MENU_NORMAL_ITEM?), or else introduce a new menu state (MENU_ADMIN_TASK) rather than changing the API. This sounds good to me and I'll look more into this option. My previous attempts at deriving the links programmatically failed miserably, but that's probably because they were based on the path.
Comment #9
Steven commentedHere is an updated patch:
Screenshot at http://acko.net/dumpx/admin-by-module.png .
IMO this is a significant usability boost to go along with the improved module installation UI, and should go into 5.
Comment #10
merlinofchaos commentedThe screenshot gets my +1. Will have to review code sometime later.
Comment #11
webchickOh, awesome! I really like this a lot!! :D
Some comments:
1. Help module contains two links to the "help" help text: one as "help" and the other as "get help." In addition, it also duplicates all of the core modules' help links, since they're "get help" elsewhere. Should we ignore this, or should we exclude help module from the list, or..?
2. My original plan was to include basically all non-dynamic paths; not just the admin tasks. So for example, including the ?q=tracker link for Tracker module, which right now is just "get help" and doesn't tell you much about what the module actually does. I don't know if we care about doing this or not though, since this is clearly labeled as 'administer by module.'
3. When a module has no links (for example, I changed ping_help to ping_helpz), it disappears from the list entirely. Is this potentially confusing for people, or should this be considered "by design?"
4. One other thing the original patch for merlin's had was the addition of IDs to the access control page, so you could go to ?q=admin/user/access#perm-user (or something like that) to skip directly to the user module's permissions. Worth including in this patch, or should it be rolled separately as a future usabiity enhancement?
5. The columns appear off-balance when I enable every module; but again, that's only because help module's listing is so looooooonnnnngg (though system is up there too). Not sure what, if anything, can be done about this, though.
6. Some of the menus are named somewhat weird, like "posts" -- probably not something that should be addressed by this patch though.
7. There's now a mix of verbs and nouns. For example, "get help" and "configure permissions" vs. "blocks." We should probably either preface administration links with something, so it looks like "administer blocks" or else change "get help" to just "help" and "configure permissions" to something like "access control." (and probably the latter, since otherwise it would be a lot to read).
Comment #12
owen barton commented+1 for #9 screenshot
Comment #13
chx commentedI do not see in my version. I mean, help eventually leads to the pages defined by 'get help' but i do not see this as a problem. If others do, then we can just get rid of help module.
for now, let's not care. Those links are far less hidden.
By design. If you are a lazy pig like me who does not write a hook_help for your module then you deserve a beating and special treatment in core :P .
Both are separate. The first is a good idea, the second two would just keep up this great patch. I have rerolled it a bit, removed the regular expressions as they were absolute overkill. The menu type check also was wrong IMO. Aside from those two lines my patch is the absolute same as Steven's.
Comment #14
webchickre #3:
I didn't mean help hook specifically; I meant when a module had no items (which was true of ping once I got rid of its help hook), it just completely disappears from the list. I'm thinking it would probably be better if all modules showed up in the list, with a message like "This module has no adminisrtation tasks." if none are found. However, when I attempted to do this myself, it was showing blocks even for non-enabled modules, so I figure someone who isn't doped up on cold medication could try this. ;)
re #7:
That actually came about as a result of this patch (was in my initial one), so I've rolled a new patch to change those links to say "help" and "permissions."
Comment #15
eaton commentedI just took a spin through the administration pages and I'm blown away by what a great patch this is. Among other things, the addition of the help links makes module-specific much easier to spot.
webchick, I think the absence of modules that lack a _menu or a _help hook is by design. This is an administration page, and purely informational blocks would be out of place IMO. Just my thought on the issue, though.
The lack of anchors on the permissions page makes the 'access controls' links a little confusing on sites with LOTS of modules installed, but I believe that's a matter for another patch. The beauty of this is that it only adds a second tab to the admin overview page: it doesn't try to hack up other stuff to add more tweaks.
on #drupal, neclimdul pointed out that modules like the ecommerce package would generate a HUGE list of 'module-specific' blocks on this new by-module page, each with just one or two links. I think that's a necessary trade-off; on the default 'by task' page, they'd all be grouped in a clean and neat fashion. On the 'by module' page, they'd be separate. It demonstrates the uesfulness of both views.
+1, big +1.
Comment #16
chx commentedSeems Steven and I agree on help to be kicked out.
Comment #17
Steven commentedCommitted to 5. Thanks everyone, this is a nice improvement.
Comment #18
moshe weitzman commentedthe sorting blocks on this page seems to be to be in "vague alphabetical" which i didn't know was supported by php :)
you guys think we should organize this by package? if so, how would that look? just asking here since thats where all the people who care are listening.
Comment #19
(not verified) commented