Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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?
Comment | File | Size | Author |
---|---|---|---|
#6 | 1128356-defaultcontent-menu-links.patch | 935 bytes | jec006 |
Comments
Comment #1
smk-ka CreditAttribution: smk-ka commentedJust 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.
Comment #2
e2thex CreditAttribution: e2thex commentedI think the issue here is the recreation that happens on cron need to investigate that.
Comment #3
mrfelton CreditAttribution: mrfelton commentedI'm having the same problem. I'll try excluding the menu links for the feature as suggested in #1
Comment #4
mrfelton CreditAttribution: mrfelton commentedYep. Removing the link items from the feature seemed to resolve it. The menu links are still created, and there are no duplicates.
Comment #5
DamienMcKennaYes, am having the same problem. I think DefaultContent should alter the Features output to replace "node/[nid]" strings with "node-name/[machine_name]".
Comment #6
jec006 CreditAttribution: jec006 commentedHere 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.
Comment #7
jec006 CreditAttribution: jec006 commentedHi,
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.
Comment #8
netw3rker CreditAttribution: netw3rker commentedI'm sorta curious about the following lines in defaultcontent.install:
shouldn't it be:
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?
Comment #9
DamienMcKenna@netw3rker: good catch, and yes, it should be. However, that deserves its own issue rather than being lumped into this one. Thanks!
Comment #10
netw3rker CreditAttribution: netw3rker commentedYeah 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.
Comment #11
Jeffrey C. CreditAttribution: Jeffrey C. commentedHello there,
Thank you all for your contribution. Can anyone confirm if there's a working patch that solves the issue? Thanks.
Comment #12
Jeffrey C. CreditAttribution: Jeffrey C. commentedPlease also take a minute to check out #1869366: Future Plan.
Comment #13
kalidasan CreditAttribution: kalidasan commentedI'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.
Expected changes is,
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.Any solution?