Menu items created twice
sammos - July 3, 2006 - 17:27
| Project: | Actions |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
With the workflow module enabled, when posting a page and adding it to the menu using the new core 4.7 menu settings in the node/add view, the menu item is created twice. This results in a duplicate in the menu that has to be manually removed in the admin/menu page.

#1
perhaps some action is re-saving the $node. maybe menu could be smarter about this?
#2
I'm experiencing this same problem where duplicate menu items are created.
I am using workflow and actions... have tried older and newer versions of each.
It only occurs when the workflow causes the "publish" action to occur... somehow node_save seems to be called twice. As you can see from the watchdog logs, and the message that is displayed on the destination page (pls see screenshots).
In action_node_publish there is the following code:
<?phpif (!$edit['defer']) {
node_save($node);
}
?>
However, $edit is always an empty array. I can't figure out where this array is supposed to be set either...
Anyone been able to resolve this issue?
Thanks.
chud
#3
I've managed to fix this problem, but I had to edit actions.inc. If someone could provide a better fix that would be great.
Basically the node is getting saved twice... and if $node->menu contains menu information, a new menu item will be created.
The solution was to unset $node->menu before the action re-saved the node.
In actions.inc, action_node_publish(), I added the following line:
unset($node->menu);... just before
node_save($node);This would need to be done for any action that has a node_save() in it... i.e. Promote, Sticky, Unpromote, Unpublish, Unsticky, etc.
Hope this helps the next person this happens to and if there's some better way to address this please let me know.
Thanks,
Colin
#4
FYI, actions that are declared batchable (in other words, they can all be done prior to a node_save()) have the 'defer' key of the $edit array set to TRUE (see actions.module line 346. This means that rather than doing a node_save, the action will just change the node property and return.
#5
Thanks John.. on my second look I kind of figured that out. But in this case there was only a single action occuring, so when array_pop($type) (line 345) is called the array became empty -- which makes sense.
So, is this a bug?
#6
Had the same issue; thanks for the quick fix.
Wanted to leave a comment letting you know it was the same issue; Publish action in workflow; even the success comment for the menu being added was listed twice:
- The menu item Parent Handbooks has been added.
- The menu item Parent Handbooks has been added.
#7
halstead and I were kicking around this problem. It seems like the most sensible place to solve this is in node_save_action(), since that'll address it for all node status changes.
Here's a patch. Credit goes to halstead if it's committed; I just rolled it. :)
#8
Hm. This fix isn't ideal, since $node->menu will be NULL for any subsequent contributed modules that rely on its presence (for example, Menu Subtree Permissions - menu_stp). We ideally need some smarter way for Actions to know "Menus have already been saved, so don't do it again."
However, for most "stock" Drupal needs, this will work.
#9
any news with this one - getting the same stuff on D5.8
#10
I agree with Moshe, that it is the menu system that should be smarter about this, since actions is just doing a simple node_save(). However, we are unlikely to see the menu system in D5 get any smarter, since it was taken out behind the barn and shot.
alexeygaponov, does the patch in #7 solve the problem for you?
#11
subscribe (since the issue I care about got duped with this).
Since the current feeling here is that menu needs to get smarter and I heard about this because of an issue with Pathauto...my gut reaction is that when actions screws up two other modules the guilt seems more likely to fall with Actions. Of course, that reaction is more than a little selfish and relatively uninformed ;)
#12
Subscribing here, nothing interesting to add.
#13
subscribing...
same issue. only I have it with D6.
#14
I'm experiencing the same error as well.
#15
The patch in #326210: menu_submit & mlid on menu creation appears to fix this issue.