Hi folks,
I have been training to learn the feature module. I generated a feature which is supposed to activate the Site wide Contact form, associated permissions, and menu items. I have built this feature module right from a clean drupal install with only the feature module (2.0-rc2) added.
When I import the generated contact feature into another clean drupal site, and enable the feature, it is listed immediately as overridden. Specifically the menu component of the feature shows the overridden status. I have to run a revert before the menu item actually appears. I assume that I am doing something wrong and I was hoping that someone could tell me what I am missing.
I have attached the generated contact feature to this request, so that people can test it out and let me know what I did wrong. I am hoping that someone can point me in the right direction. I have googled this particular issue and so far I have not found any resolution to my particular dilemma. Thanks in advance for your help.
Cheers,
Mitch
| Comment | File | Size | Author |
|---|
Comments
Comment #1
mpotter commentedDid it work after running the revert on menu items? Some items, such as menu items, are problematic with Features since they do not have unique identifiers are do not have good hooks in Drupal for supporting Features. So needing to revert a feature after install isn't necessarily a problem. If the feature continues to be marked as overridden, use "drush fd featurename" to dump the differences to see what's happening. Might be a missing module (or module not enabled) on your new site, for example.
Comment #2
christowm commentedHi mpotter,
Thanks for the reply. The feature does show the menu item after I execute the revert command. But what I don't understand is, why is this not working from the getgo.
I have downloaded other features from d.o. and they do not require an explicit revert after installation. So clearly I am not doing something right. For example the panopoly_news app has a menu item in it and it shows up during initial install without incident.
I have added the feature that I created to the previous message. If you could be so kind and point out where I am doing something wrong, I would really appreciate it.
Cheers,
Mitch
Comment #3
enorniel commentedHello,
I have the same behavior with a feature I made. Some parts of it are overriden directly after I installed it.
When I revert it, I have 2 times the parts not overriden and 1 time the parts overriden which still are marked as overriden.
I revert again, 3 times the not overriden and 2 times the overriden and still marked overriden. Etc...
When I do a diff, it is overriden by core elements of the drupal install.
I install drupal via drush.
Can you help me ?
Comment #4
c4rl commentedThis is also happening to me in D6.
Comment #5
c4rl commentedClarification: I am having the same issue as it applies to menu_links.
From what I can tell, running a feature revert destroys the cache_menu entries for the said menu items, but does not adjust parameters in the menu_links table. Then when a cache clear happens, the cache_menu entries are rebuilt from the menu_links table thereby overriding the feature.
Will dig into this further to see if I can put together a patch, at least in D6 :)
Comment #6
c4rl commentedHm, I take that back :) the values are getting written to the DB correctly, but are somehow being rewritten on cache clear.
Comment #7
c4rl commentedI think the issue here actually is that when menu_rebuild() runs during a cache clear, it reverts the status of any menu_link entry that has been defined via the system module (that is, where module=='system' in the menu_links table). Any menu entry that is created by another module (from any hook_menu, and things like views or panels) will be reverted to whatever state that entry was defined by the originating module. Reverting the feature will restore the feature-exported state, but only until the next time menu_rebuild() is called.
Unfortunately, there are certain parameters of menu items (such as `expanded`) that are simply not accounted for from modules that export their own menu links (i.e. neither views or panels supplies these in D6).
So, I think there's only a workaround for this: Only export custom menu links.
Do not export a menu entry as part of the native configuration any panels or view; instead simply create a custom menu item via the admin UI that points to the corresponding path for the panel or view (or whatever). This way, anything that had a module=='system' entry will initially go away (will behave like MENU_CALLBACK instead of MENU_NORMAL_ITEM) and will have module=='menu' for the custom item.
I'm going to mark this "Works as designed" but feel free to re-open if this doesn't solve your problem.