Split module settings into sub-menus

Good idea. However, not trivial.

With the re-factored code in 5.x-2.x, it might be possible to use the 'package' information of all modules and group them by package (Settings only). I think, that would be the best option. What do you think?

This can certainly considered as a bug and needs to hit 5.x-2.x.

Attached patch implements the proposed solution in #1 -- each contrib module that defines a 'package' in its .info file is moved into a corresponding settings category (package name).

Certain core modules are moved into a new category 'System'.

Modules that do not define a package, are not moved. Thus, this is also great QA tool for module maintainers... ;)

Let me know what you think. I've tested it on a site with 56 enabled modules and the results are quite impressive.

Please bear in mind that this patch is against latest 5.x-2.x.

Any feedback? I like it very much so far. We probably should use the same categorization for the Drupal.org issue queue links.

Re-rolled patch against latest 5.x-2.x.

Re-rolled patch against latest 5.x-2.x after code clean-up.

@eigentor
They're the instructions I followed and it applied for me. Did you apply the patch to 5.x-2.1 or 5.x-2-x-dev (the development snapshot)? The patch is against the dev release.

@sun
Notes I took while taking a tour around a clean install of Drupal 5.5, patched admin_menu and two roles set up:

site administrator: who can access everything.
content manager: with 'administer nodes', 'administer content', 'access administration menu' and the 'administer filters' permissions.

There's some questions in here. I apologise in advance if they're stupid ones.

Logged in as site administrator:

"Yay! Look at how all those menu items that I have so very little cause to use all that often have just been tidied away. That's a +1 right there."

Certain core modules are moved into a new category 'System'.

The expected core settings are moved under system menu item. Paths are correct with both ?q= and 'clean-urls'.

each contrib module that defines a 'package' in its .info file is moved into a corresponding settings category (package name).

Installed and enabled Voting Api and fivestar modules. Both are in the Voting package. As expected Voting api and fivestar settings links are moved under settings category Voting.

Installed and enabled Javascript tools including Tabs, Collapsiblock and Active search modules. Despite all info files defining the package as Javascript tools there is no settings category for Javascript tools and the menu items aren't moved.

Qn: Modules that don't define $items['access'] so use the access rights of the parent menu item aren't moved, is this intentional/desirable?

[EDIT] Qn: Is it safe to assume the path to a modules settings will always be $path = 'admin/settings/'. $module?
(Off-hand I can only think of one module where this isn't the case, that's form inspect).

Logged in as content manager:

The core settings (that I didn't expect to see) are not moved under category System (I expected that).

Qn: Logged in as content manager I expected only 'Content management' with the relevant child menu items and 'Site configuration' with the single child item 'Input format' to be visible. However 'Logs', the icon menu items 'administer' and 'run cron', and ALL the site configuration menu child items are also visible. Are my expectations wrong?

As content manager after assigning voting api permissions to the role:

As expected Voting api link is moved under settings category Voting.

We probably should use the same categorization for the Drupal.org issue queue links.

I'm not sure you should but that's because I look for issue queues by project name. What package it's in is irrelevant to me here.

Which leads to -

Qn: Currently links are being created to issue queues that don't exist. Modules such as Views UI, JS Tools Tabs, all of the CCK project don't have issue queues of their own because they're project components. If I have these modules enabled it results in several redundant links to the 'all issues' page at d.o.

Wouldn't it be better to instead link just to the unique project issue queues rather than duplicate them for each module?
e.g.

- CCK issue queue
- Views issue queue

Instead of

- Content issue queue
- Node reference issue queue
- User reference issue queue
- Views issue queue
- Views UI issue queue

And

Qn: shouldn't these urls be created using $url = 'http://drupal.org/project/issues/'. $info['project'] ?

New patch.

Qn: Modules that don't define $items['access'] so use the access rights of the parent menu item aren't moved, is this intentional/desirable?

No, that's gone now. However, this needs thorough testing.

Is it safe to assume the path to a modules settings will always be $path = 'admin/settings/'. $module?

No, it's not. However, AFAIK there is no way to determine the real paths of module setting pages. So I doubt we can do much here.

Currently links are being created to issue queues that don't exist. Modules such as Views UI, JS Tools Tabs, all of the CCK project don't have issue queues of their own because they're project components. If I have these modules enabled it results in several redundant links to the 'all issues' page at d.o.

That is fixed in this patch, too. Now using 'project' information of module .info files for d.o issue queue links. Downside: 'project' information is added by packaging scripts run on d.o, hence there are no issue queue links for direct CVS checkouts.

Not good: The new package grouping menu items are linking to admin/settings and because of that, the menu item id of admin/settings is changed in admin_menu's path index afterwards. This means that a subsequent call to admin_menu_add_item() with the parent menu item id of admin/settings would add an item below the last package grouping menu item instead of "Site configuration".

IMO it would be best, if those grouping menu items wouldn't be a link at all. However, that is not easy to implement, because we need to assign a path for grouping items to move other items below them.

Attached patch works, but I'm not really happy with it.

@eigentor: Yes, definitely. But I still don't have an idea that works out.

Subscribing

When I ran this patch, I received error messages in Terminal, telling me that the patch failed on lines 149, 192, and 212. How do I rectify this?

If it is helpful to know, I also have Admin. Menu Dropdown installed.

I wonder whether

- some hook_menu_alter() magic would allow us to parse out the module package name of all first-level items below admin/settings, and

- move them below new, injected MENU_DYNAMIC_ITEMs for the package name, i.e. admin/settings/[package-name]

Bug? I clearly must have been blindfolded back then in 2007.

Marked #430294: Cycle through long menu lists as a duplicate of this issue.

subscribing

I seem to have this issue in Drupal 6 as well

subscribing

subscribing

Marking as duplicate of #508458: Config and modules page. You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.

However, thanks for taking the time to report this issue.