I have a view that takes 2 arguments, and a primary links menu similar to:

Project name (static page)
-All entries (taxonomy list)
-Support (view/project_name)
--Bug reports (view/project_name/bug)
--Feature requests (view/project_name/feature)

When I select "All entries", the menu properly shows that link in black and still has the main menu header expanded. When I select "Support", the entire menu collapses. This makes it impossible to reach any menu under "Support", since when it is selected the "project name" menu closes and hides all of its elements.

As a guess, I suspect that the drupal menu system does not like the arguments.

Comments

pwolanin’s picture

There may be a bug in terms of wildcards in the path and expanding down. Maybe related to: http://drupal.org/node/170309

pwolanin’s picture

Of course, if these are just args (as in things appended to the path) the D6 menu system really has no way to know about that unless we do something like we do for search module or taxonomy: http://drupal.org/node/157510 http://drupal.org/node/180301

see also, another issue that may have some bearing: http://drupal.org/node/184955

RoboPhred’s picture

Title: Primary links menu block not following view page. » Primary links menu not following view page when page is not root level.

I poked around a bit and found that the issue only occures when the page is not on the root level.

The page path for the view that has the issue is
/project_views/support

I cloned the view and created the new page at
/support
This one works as expected.

RoboPhred’s picture

Title: Primary links menu not following view page when page is not root level. » Primary links menu not following view page.

Disregard the last find. The reason it was working apparently was because I had a menu item on the same level that include the argument-less link to the view.

Project name (static page)
-All entries (taxonomy list)
-Support (view/project_name)
--Bug reports (view/project_name/bug)
--Feature requests (view/project_name/feature)
-Test (view)

In this menu setup, everything works as expected.
Interestingly enough, it also continues to work if I disable the Test menu item, but stops working if I fully delete it.

In this case, it looks like the menu is completely ignoring the arguments and trying to select the direct path of the view page.

RoboPhred’s picture

Any updates on this? This is preventing me from taking a site live.

merlinofchaos’s picture

As far as I can tell, this is a Drupal core bug, as pwolanin indicated above. Not much I can do about it.

pwolanin’s picture

@RoboPhred - please post more details about the configuration and where you are seeing the problems. From your initial post it's impossible to tell what the menu paths are vs. args stuck on to the ends of path, etc.

For me to be interested in this, I need a simple and exact recipe to reproduce the problem, and then I hope very much that you will jump in and help test any possible solutions.

RoboPhred’s picture

Sorry for the late response, my work on my website has been halted due to the dreaded "real life issues"

I am in the middle of recovering the site from an erratic upgrade to the new core, but will try to watch this thread and help out.

The view has these possible arguments:
view
view/$arg1$
view/$arg1$/$arg2$

arg1 and arg2 are matched to cck fields.

Here is the primary links menu setup, which I already posted:

Project name (static page)
-All entries (taxonomy list)
-Support (view/project_name)
--Bug reports (view/project_name/bug)
--Feature requests (view/project_name/feature)

From what I can recall, drupal failed to find the page url for "view/project_name/feature", since the last 2 entries are arguments. However, it did work properly with "view/project_name", where only the one last entry was an argument.

I will try to test it out as soon as I can, once I get the website functional again.

RoboPhred’s picture

Tested again and the issue is still active.

merlinofchaos’s picture

Does this patch to core http://drupal.org/node/170309 fix the issue?

merlinofchaos’s picture

Does this still happen with Drupal 6.4?

RoboPhred’s picture

It actually started working before that update. I am not sure what changed, but I think it was my use of breadcrumb modifying modules.

merlinofchaos’s picture

Status: Active » Fixed

Great!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

thekenshow’s picture

I'm seeing very similar behaviour to the original description with Drupal 6.10 and Views 6.x.2.3. I lose the Primary Links active trail when I link a nested menu item to a view + one argument. If I link it to the view path without the argument, the active trail is preserved. Strangely, if I manually append the argument to the url and load the view, the active trail is still maintained.

So the active trail is lost with the following, where "content/products/id" is the view path:

Fire Systems
-- Control Panels <-- linked to "content/products/id/8"
-- Detection

But preserved with this:

Fire Systems
-- Control Panels <-- linked to "content/products/id"
-- Detection

As noted, manually appending the "/8" and loading the page preserves the active trail. The only two modules in use that I can imagine affecting this are pathauto and menu block. Any pointers would be most welcome.

ifernando’s picture

I found that primary link does not follow view pages (the menu is not expanded) if I create a menu item directly pointing to my view path (/?q=members in my case).

The solution is to remove this menu item and use the view's Page Settings | Menu option to create the menu item.

wapnik’s picture

Status: Closed (fixed) » Active

What about multilingual sites, if i want that menu item translated?

gagarine’s picture

Version: 6.x-2.x-dev » 7.x-3.3

If I create the link from the menu and not from the views I get this issue.

See #1609270: Menu block does not appear on views pages even if they're linked in the menu