Node menu link tokens do not work with OG Menu module and Workbench Moderation

Patch works for me! Thanks a million :)

+1 RTBC this worked for our project as well on a site using OG, OG Menu, and Workbench/Workbench OG

This works for me too! We are using OG and OG Menu.

This works perfectly

+1 RTBC on project with og_menu and workbench_og

Is there any way we can add tests to confirm this works as expected?

Right, so as usual I only stumbled upon this issue after having debugged it completely. But given that I managed to figure out exactly what is going wrong, I'll shed some light on it here and will end by stating how we could write a test for it, but why it may be unnecessary too.

Disclaimer: We encountered the same problem, but with Group Menu instead of OG Menu. The former having borrowed code from the latter and thus suffering from the same issue.

Where Token is bugged

The way the Token module tries to replace a [node:menu-link] token (or any child tokens of it), it looks for $node->menu in token_node_menu_link_load(), however this is only present on node edit forms because they call node_object_prepare(). So when dealing with a regularly loaded node (such as during workbench moderation), it does not find the $node->menu property and loads it by directly calling menu_node_prepare() instead.

What is wrong with this is that it does not account for other modules that may also manipulate the $node->menu object through their own hook_node_prepare(). By calling one implementation directly, it shuts out all other modules.

Where core is inconsistent

The fact that this can be a problem in the first place is because core does not properly load several node properties during hook_node_load(), but chooses to do so during a "node prepare" or a form alter. Main offenders that cause issues are the $node->path and $node->menu properties.

Why it breaks when using OG/Group Menu

So why does this mainly manifest itself when using either of these two modules? It's because both modules allow a content type's nodes to be added to menus that were not configured on the content type edit form. The checkboxes there are stored in the menu_options_NODE_TYPE_HERE variable which in turn is used as a condition when retrieving menu links in menu_node_prepare().

So ideally, both modules should store the truly available menus in that variable, but as it turns out there could be a lot of menus because of the way both modules work, I can imagine why they chose not to do that. They did, however, implement hook_node_prepare() as well in order to properly find and load the right menu link.

Conclusion

So even though both Token and OG/Group Menu have minor flaws that -when added together- cause this bug, I feel like the easiest fix is the one proposed here: Make Token properly invoke all node preparations instead of just the Menu module's implementation. In a perfect world, the other modules would be fixed too by properly setting the menu_options_NODE_TYPE_HERE variable.

Why I feel this does not need a test

All Token is doing wrong here is calling a hook implementation directly instead of using the right channels. We could write a test where a test module that implements hook_node_prepare() has to be enabled, but then we'd actually be testing the hook system which is already covered.

A thoroughly investigated RTBC from my end.