Been struggling with a strange issue with storing menu links via features, which I finally tracked down.
If a menu link is stored in features, but is also stored elsewhere in code (e.g. set as part of a view, or with page manager, etc...), the following can happen:
A menu revert with features will have the expected result: the menu items will revert to how they were originally stored.
However, once the caches are cleared, the menu will be rebuilt based on the original values stored via Page Manager, Views, etc, overriding the values specified in the feature menu-links, which could have the effect of changing menu order, changing (in)visibility, etc.
The workaround is to ensure that all values are set correctly in the original source and exported from there, without performing any overrides via the menus system (admin/build/menu) or storing these via features menu links.
I can't see any easy way to fix this:
- We could try to prevent exporting menu_links that are already defined and exported elsewhere, but that would probably require separate checks for each type of exportable content
- We could add a hook_menu_alter to interrupt the menu rebuild and re-inject the menu information stored in features, but that approach seems dangerous and assumes that the menu links stored in features SHOULD take precedence over the menu links stored elsewhere (e.g. views)
For now though, I think it's just a question of remembering NOT to try to export menu links which are already defined in code elsewhere.
An intermediate "fix" might also be to force a rebuild of the menu router after a revert. This wouldn't necessary fix anything, but would avoid the confusing unstable state between a revert and clearing the cache - that brief period when the menu_links in features takes precedence over what is stored in cache elsewhere.
Comments
Comment #1
mpotter CreditAttribution: mpotter commentedClosing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.
Comment #2
dooug CreditAttribution: dooug commentedWe are experiencing this "confusing unstable state between a revert and clearing the cache" described above with the latest commit of Features 6.x-1.x-dev and Pressflow-6.26.2.
Although there are other issues that seem to be duplicates, I have yet to find one that provides a solution:
#910456: Custom menu links not saved
#1300098: menu_links Unreverting when caches are cleared
I'll try to replicate on a vanilla drupal install and post back here.
Comment #3
dooug CreditAttribution: dooug commentedAfter about 5 hours of repeatedly trying to replicate this bug and looking through the code to figure out what is going on, I have been able to replicate the bug with the following steps: (I should've read the original post more carefully.)
Steps to replicate: I put my example Menu item title in parenthesis to show the state of it as it is changed.
Work-around solution:
Don't edit the Menu items through the Menu UI if they are stored in code. Make changes to menu items where the router_path originates (in the view).
The problem originates in the fact that this menu item exists in two places: once in the feature code in featurename.features.menu_links.inc and again in the view (it doesn't matter if the view is exported or not).
Comment #4
dooug CreditAttribution: dooug commentedWell, after all that. I found this other post #927576: Menu links not set as customized, revert when menu rebuilt and this patch in comment #10 and can confirm that fixed this bug.