I'm not positive whether this is best solved in Token, OG Menu or Workbench Moderation (or maybe somewhere else?) but I have a site with all three enabled. I have a content type setup as a group and others setup as group content and setup to use OG Menu and have moderation enabled through Workbench Moderation. Using pathauto, one of the patterns is [node:menu-link:parents:join-path]/[node:title]. This works when editing the node from the node form, but not from other places.

IE: from the node edit form, given the node title is "Build and Install" with OG menu parents "Documentation" > "Developers"; the path might be:

When using the moderation state change links the path will incorrectly get changed to:

For example, using the Moderation state links on /admin/workbench/needs-review from Workbench Moderation, the menu-link path is not loaded. I believe this is because menu_node_prepare() only checks the menus that are configured for that content type, and not any of the OG menus.

I can also reproduce this by doing something like this in drush: drush php-eval '$node=node_load(824);node_save($node);'

Proposed Solution

In token_node_menu_link_load(), instead of calling menu_node_prepare() directly we could node_object_prepare($menu_node); to allow OG Menu and other menu-related modules to properly load menu link data.

Thoughts? I'll submit a patch soon once I test it on my project.

#1 token-menu-link-token-2238191-1.patch1.48 KBjojonaloha
PASSED: [[SimpleTest]]: [MySQL] 347 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


jojonaloha’s picture

Status: Active » Needs review
1.48 KB
PASSED: [[SimpleTest]]: [MySQL] 347 pass(es). View

The attached patch appears to be working for me. I was having a little bit of an issue at first. You may need to check that the 'og_menu_enable_' . $type variable is true for your content type.

seanB’s picture

Status: Needs review » Reviewed & tested by the community

Patch works for me! Thanks a million :)

dustinleblanc’s picture

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

rvilar’s picture

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

acidaniel’s picture

This works perfectly

thelmer’s picture

+1 RTBC on project with og_menu and workbench_og

Dave Reid’s picture

Issue tags: +Needs tests

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

kristiaanvandeneynde’s picture

Issue summary: View changes

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.


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.