hi,

first of all thanks for the great module.

Then maybe someone can create a new version with the patches? Without them the module produce failures.

But now to the issue.
If i export some content with menu links on main and footer as feature i have duplicate menu entrys. Not every entry have duplicates. Sometimes three or two of them and sometimes it works correctly.

My fix was that i remove the menu links in .features.content_menu_links.inc
So i got my menu entries without duplicates.

Anybody have the same problem?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

smk-ka’s picture

Just a sidenote: this happens whenever the hard-coded node id in the exported feature of your content menu link differs from the actual node id of your content during import time. Features' content menu link import routine tries to look up the node link as it appears in your export, and doesn't take Default Content's machine name into account. Apparently, as @Ciraxis noted, Default Content seems to restore the menu link on its own, so the solution really seems to be to just omit it from the feature.

e2thex’s picture

Assigned: Unassigned » e2thex

I think the issue here is the recreation that happens on cron need to investigate that.

mrfelton’s picture

I'm having the same problem. I'll try excluding the menu links for the feature as suggested in #1

mrfelton’s picture

Yep. Removing the link items from the feature seemed to resolve it. The menu links are still created, and there are no duplicates.

DamienMcKenna’s picture

Yes, am having the same problem. I think DefaultContent should alter the Features output to replace "node/[nid]" strings with "node-name/[machine_name]".

jec006’s picture

Here is a patch to [help with] the menu links issues created by them being recreated on cron.

This is not a final solution, merely a way to resolve some of the issues that this is causing.

jec006’s picture

Hi,

I've resolved this issue - however, the patch provided here causes an issue with reinstalling modules/apps or installing multiple modules at a time

I've updated the code to resolve this issue and commited it here: http://drupal.org/commitlog/commit/18820/0d7ad4c9553bad5b3f818b21b55411c...

Its in the alpha3 release.

netw3rker’s picture

I'm sorta curious about the following lines in defaultcontent.install:

->condition('type', 'module')
->condition('name', 'defaultcontent_install')
->execute();

shouldn't it be:

->condition('type', 'module')
->condition('name', 'defaultcontent')
->execute();

or is there a special drupal 7 thing i dont know about that creates a temp name for modules that are in the process of being installed?

DamienMcKenna’s picture

@netw3rker: good catch, and yes, it should be. However, that deserves its own issue rather than being lumped into this one. Thanks!

netw3rker’s picture

Yeah I thought I was was reviewing the diff of the changes related to this issue when I saw that - it seemed like a strange change for this issue ;). I'm still new to the whole 'git browser on drupal.org' thing.

on another note (and related to this issue) I just finished helping one of my clients through a massive problem with getting double menus when features were reverted. For them, it boiled down to not realizing that when you export nodes that have menu items defined for them, they bring their menu with them on export and the associated menu item doesn't need to be checked under content-menu-links. That's the right functionality, but is confusing when people dig through the export settings and see the menu link that is associated with their content. an example of this path structure is:
-- node 1 (just export the node)
-- --node 2 (just export the node)
-- -- --node 3 (just export the node)
-- node 4 (just export the node)

They did run into circumstances where a node had 2 menu links (one from the node, the other added via the menu system). in those situations they had to export the node, and find the *other* menu link in order to get both links to show. the example here is:
-- node 1 (just export the node)
-- -- node 2 (export the node)
-- node 2 (export the menu link)

In yet another situation, they had a menu paths that parented on views or menu items provided by things other than nodes. in those situations they had to export the nodes, and find the menu link for the random item and check it. this was an example structure:

node 1 (just export the node)
- view (find and export the menu link)
-- node 2 (just export the node)

these are probably not something that can be programatically fixed, but documenting what happens under these circumstances will help these users out a lot.

Jeffrey C.’s picture

Version: 7.x-1.0-alpha1 » 7.x-1.x-dev

Hello there,

Thank you all for your contribution. Can anyone confirm if there's a working patch that solves the issue? Thanks.

Jeffrey C.’s picture

Please also take a minute to check out #1869366: Future Plan.

kalidasan’s picture

Issue summary: View changes

I'm using Menu Token module for dynamic user ID.
Getting two times entry on feature revert.

Ex:
Below menu entry already available in DEV server.

1. Settings with path <user>

Expected changes is,

1. Settings with path <user/[user:id]/mypage>

Updated above Settings value with menu token module & Recreated feature.
While revert feature(Drush fr) on DEV server, getting two times menu entry as mentioned below.

1. Settings with path <user>
2. Settings with path <user/[user:id]/mypage>

Any solution?