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

mpotter’s picture

Status: Active » Closed (won't fix)

Closing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.

dooug’s picture

Version: 6.x-1.1 » 6.x-1.x-dev
Status: Closed (won't fix) » Active

We 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.

dooug’s picture

Priority: Normal » Major

After 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.

  1. Install the latest Drupal 6. Install/enable the dev versions of Features, and Views modules.
  2. create a custom menu
  3. Create a view with a Page view display and set a "normal menu entry" for that page in the custom menu. (Menu title is "TESTING View Title")
  4. create a feature that includes the custom menu and the view and the menu link.
  5. Now through the /admin/build/menu interface, customize the menu link in your custom menu. (Menu title is now "TESTING View Title Changed in Menu")
  6. Do a feature recreate (or drush feature-update) on your feature to commit the changes you made to the menu link
  7. Now change your menu link in the custom menu again (Menu title is now "Whatever")
  8. Do a feature revert to return the feature to the default state (this is works as expected) (Menu title is now "TESTING View Title Changed in Menu")
  9. Now do clear the menu cache (drush cc menu) and you will see that the menu link is returned to the settings in the View display, and the customizations to the menu_link item through the menu interface are lost! (Menu title is now "TESTING View Title")

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).

dooug’s picture

Status: Active » Closed (duplicate)

Well, 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.