Bundle this functionality in context itself?

There's a lot of background about other modules I'm not familiar with, but I don't think the problem Context: Menu Block solves (#751700: Setting active with Context Module) and the problem the patch in #835090: Context Reaction: Set menu trail solves are they same.

That is, let's say you have a menu like:

• Parent
• Child

You want Child to be active (not in the active menu trail: Child is the menu item you want selected) when you're on page with a path node/3. So you create a context with a condition Path: node/3 and a reaction Active Menu: Child. This should set the active class on the Child menu item.

But this doesn't work with blocks Menu Block creates: nothing ever gets set on the Child menu item: not active, not active-trail.

Context: Menu Block gets this expected behavior to work without configuration by traversing the menu tree Menu Block uses, determining if the context has been set, and adding the active class to the menu item.

While I don't doubt certain use-cases would not favor one solution over the other, active menu and active trail are not the same, and I know from my own experience, both could be themed differently.

There should be no reason for users to have to modify all of their existing contexts (and themes) to use active trail over active menu: and I don't think many users would know the difference between the two. If anything, the functionality Context: Menu Block provides would be better off in Menu Block, but it's a specific enough use-case that pushing for Menu Block to support Context isn't that much of thing.

I'm interested to see if there's something I'm missing from the other issue though.

I'll try to take this point-by-point:

It guess it all comes down to setting the "active" class, which is really something that only plays out at the theme level, correct? Is is safe to say that other modules do not use the "active" property of a menu item for their processing logic?

I am lead to believe that the menu trail is different in the respect that other modules do inspect (and react to) the current menu trail. If I am correct, this is how menu block controls the visibility of a 2nd or 3rd-level menu block.

I can't speak for every other module out there; I can only speak from my own experience. The active menu item and the active trail are not necessarily interchangeable, and it's not a requirement that modules (or themes, for that matter) to favor one over the other in their implementation of menu trees.

So it looks like getting menu block to properly respect/display the active menu item set via context (and apply the "active" class) requires your Context: Menu Block module, and getting menu block to property control the visibility of 2nd and 3rd level menu blocks (based on the current context) requires a patch to allow context to set the active menu trail.

The first part is correct, the second part isn't. To get the active class set for any menu item, including child menu items, using the reaction active menu you can use Context: Menu Block. It requires no additional configuration or module.

If I'm on track so far, it would seem to me that all these problems could be solved if Drupal automatically applied the "active" class to menu items that are listed at the end of the active menu trail. This way, we could just be sure to set the active menu trail (via context or otherwise) and our active menu item would also be set for us. Still, I'm suppose there could be cases where the active menu item would need to be somewhere other than the end of the trail... our outside of it completely... but I don't know how common that would be.

In Drupal 6, there can be only one active menu at a time. So, let's say I'm on the page Foobar It exists in two menus, navigation and primary links:

• Navigation
  • Parent 1
    • Foobar

• Primary Links
  • Parent 2
    • Foobar

Depending on menu priority, either navigation or primary links (not both) is going to get the active trail applied to it. So, if someone is going to use an active trail reaction, they need to know this about the menu system, and aren't going to be able to set this for more than one menu.

However, as it is now, someone can merely use the active menu reaction and Context: Menu Block and not have to worry about this: the active class will be set on all menu blocks.

I don't really have any objection if there was another reaction in Context that modified the active trail (although if you wanted my personal opinion, I think active trail is unintuitive for most people), but as I explained on #835090: Context Reaction: Set menu trail, I think any solution that requires users to go back and modify their contexts and themes that rely on setting the active menu item and are currently working as expected (with Context: Menu Block or otherwise) isn't really much of a solution.

As of right now, I don't see anything that's actionable in Context: Menu Block: either some functionality gets rolled into Context or Menu Block that's equivalent to the functionality Context: Menu block provides, or the status quo remains. Marking it as by design. The original issue looks interesting; I'll be following its progress.