Currently, when an invalid path somehow ends up under a menu item (with children), the matched menus are shown and they are expanded despite the "Page not found" or "Access denied" message. It would be more consistent with regular Drupal behavior if the menu trail is simply not activated.

Of course, I know that the theme could simply override the 404 not found page. I also understand that you could set a fast 404 page. Nevertheless, this issue seems like something this module should account for.

So far, the only workaround I have found is to use hook_page_delivery_callback_alter() to hijack the page delivery callback (stashing the original for the hijacking callback) and then testing $page_callback_result for MENU_NOT_FOUND, MENU_ACCESS_DENIED, and MENU_SITE_OFFLINE to suppress the menu_trail_by_path_init() behavior.

Comments

zhangtaihao’s picture

zhangtaihao commented

Actually, I've just remembered that wouldn't work because hook_init() happens before menu_execute_active_handler().

Any more ideas?

(EDIT: One might move the menu trail activation mechanism into the hijacking delivery callback itself to trigger before the menu blocks are built.)

SeriousMatters’s picture

SeriousMatters commented

Perhaps hook_init() isn't the best hook for this. I'll play around with hook_page_delivery_callback_alter()

zhangtaihao’s picture

zhangtaihao commented

Thanks. You probably already know this, but Menu position seems to do that for exactly the same reason.

SeriousMatters’s picture

SeriousMatters commented
Assigned: Unassigned » SeriousMatters

After some research, hook_page_delivery_callback_alter does seem more appropriate than hook_init. I guess we should change the hook.

But I still haven't figured out how to include 404 checking mechanism. $page_callback_result seems to be a local variable in menu_execute_active_handler(), not hook_page_delivery_callback_alter().

By the way, I wonder if having the menu trail mechanism on 404 pages would be a desirable effect. Perhaps allows the user to enable/disable 404 checking via UI.

zhangtaihao’s picture

zhangtaihao commented

I've had to use a similar approach to hack it in some other custom project. It's not pretty, but I quite literally hijacked the page callback to receive the result. The argument would then be $page_callback_result.

Then again, if we all think of doing it, then hijacking it probably wouldn't really work either.

SeriousMatters’s picture

SeriousMatters commented
Assigned: SeriousMatters » Unassigned
Status: Active » Postponed

I don't see a way forward at the moment. Therefore postponed.

SeriousMatters’s picture

SeriousMatters commented
Issue summary: View changes

Updated wording to reflect hidden menu for normal error.

davy-r’s picture

davy-r commented
Version: 7.x-2.x-dev » 7.x-3.x-dev
Issue summary: View changes
Status: Postponed » Closed (works as designed)
Related issues: +#2303693: Allow other modules to alter menu_trail_by_path's parent candidates

You probably can use the hook_menu_trail_by_path_parent_candidates_alter() to accomplish what you want.