This is a minor bug. The menu system requires a local task to have more than 1 child in order to create secondary local tasks. In other words if a local task only had 1 child, menu system would not create a secondary local task menu item.

This patch fixes that with the addition of 1 character in the code.

andre

CommentFileSizeAuthor
menu_inc_1a.patch826 bytesandremolnar

Comments

dries’s picture

dries commented

I'm pretty sure this patch would break some pages. Some modules have a tab and a subtab that show the same page. The tracker page, for example, relies on the fact that the subtab does not get shown when there is only one subtab. However, when there are two or more subtabs, they are being visualized. I guess this needs some more thought.

andremolnar’s picture

andremolnar commented

hmmm... Well, I certainly don't think that this should be the expected behaviour of the menu system. A child menu item is a child menu item, and I would expect that it show up if I create that child in hook_menu. When patching user.module it took me over half an hour to track down this bug (a single missing character was easy to over look).

Nor do I personally think that the menu system should accomodate exceptions of the sort described in tracker.module. It should be the module's job to decide when to create a local task in hook_menu using logic local to the module.

IMHO if applying this 'breaks' modules - so be it. It would force a necissary code/logic improvement in those modules.

andre

dries’s picture

dries commented

Well, the problem is that the tracker module can't determine whether to add the subtask. It should only be added when another module adds a second subtask. I'll explore this some more.

killes@www.drop.org’s picture

killes@www.drop.org commented

Dries doesn't like it as is.

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Active » Needs work

There is a patch after all.

drumm’s picture

drumm
he/him
Location NY, US
commented

-1

There are quite a few cases where the current behavior is desirable. Modules often add local tasks to pages which were not made by the module itself. This is helps the end UI to not resemble the underlying modular structure.

The current de-facto standard is that a local task's title should not be necessary to the page if it is the only local task by default and should provide distinction from potential additional local tasks.

What is the user.module problem which led to this issue?

moshe weitzman’s picture

moshe weitzman commented
Status: Needs work » Closed (works as designed)