I'm encountering some strange behavior. Not sure whether this should be in the entity or features queue. My features module is 7.x-1.0-beta3.
I have an entity of custom type "datasource" that I've added to a feature. I exported the feature to code and the features UI shows that the datasource entity in the feature has status "default". Editing the entity (modifying the name, for example) results in the features UI showing the entity as "overridden". So far so good. Upon reverting the entity (via either the features UI or drush), the entity still shows as "overridden" in the features UI. Worse, the entity is no longer in the database! For some reason, reverting the entity deletes it.
Any ideas? Thanks!
Comment | File | Size | Author |
---|---|---|---|
#12 | 1211272-save-component-on-revert.patch | 519 bytes | Josh Waihi |
Comments
Comment #1
jdleonardOne more tidbit: the module database field for the entity is NULL even after exporting to code.
Comment #2
jdleonardI'm pretty new to features (and entity). Looks like module = NULL is normal in this case.
Looks like this problem was encountered with views too. Perhaps a similar fix needs to be applied to entity?
#1157048: Feature-packages appear overridden when they are not
Comment #3
jdleonardThis appears to be fixed in beta10 :)
Comment #4
jdleonardStrike that. It just happened again. I haven't been able to nail down good repro steps.
Comment #5
klausiSounds like your entity does not exist in code anymore? If you revert an entity it gets deleted from the DB and newly imported via the default() hook. If that default hook is not present anymore the entity of course vanishes.
Comment #6
jdleonardI wish it were that simple, but the entity definitely still exists in code. Re-installing the module gets it back in the database as expected. I don't know where to begin debugging this.
Comment #7
klausiWhere do you define your entity? You should use hook_default_YOUR_ENTITY_TYPE_NAME()
Could you post the code?
Comment #8
jdleonardentity: tbm_school
Comment #9
fagoThat looks good to me, does it still happen with entity API >= beta 10?
Comment #10
jdleonardOnce again, I can't repro. I'll reopen if I encounter this again, thanks.
Comment #11
jdleonardRe-opening and moving to features queue.
I've encountered this again, this time with ctools/panels. Reverting a page variant removes it instead of reverting to the variant in code.
Comment #12
Josh Waihi CreditAttribution: Josh Waihi commentedafter finding issue reverting nodequeue features over in #373174: Export and import capability for nodequeue I found that this was because features ctools implementation didn't re-save the deleted component. Attached is a patch that seems to fix this.
Comment #13
Josh Waihi CreditAttribution: Josh Waihi commentedUpdating status for review.
Comment #14
Josh Waihi CreditAttribution: Josh Waihi commentedMaking title more relevant.
Comment #15
jdleonardOnce again, I'm having trouble reproducing the bug I reported both with and without #12. All I can say for now is the patch doesn't seem to make things worse.
Comment #16
David Stosik CreditAttribution: David Stosik commentedSame here. To try and reproduce bug :
- have a feature describing a content type
- create a new node for this content type, and fill as many fields as possible
- change any setting concerning a field on this content type (let's say, how is displayed the body in default display)
- now, the feature is in "override" state, let's revert it
- LOOK your node is still here, but all content is gone !
- check in database ? all field_data_ and field_revision_ tables concerning your content type are empty
Sadly, patch in #12 doesn't fix anything...
Comment #17
David Stosik CreditAttribution: David Stosik commentedComment #18
roborn CreditAttribution: roborn commented@David Stosik are you reverting via Features UI or Drush? I get the same issue as #16, but only when using Drush.
Comment #19
Simon Georges CreditAttribution: Simon Georges commented@roborn, David is mainly reverting using Drush (I work with him). I don't think we've tested using the UI. Just so you know, there's no problem any more after applying patch from #1302228: field_has_data() returns inconsistent results – possible data loss.
Comment #20
roborn CreditAttribution: roborn commented@Simon thanks for the link. Me and thomjjames were trying to solve this problem, and he stumbled upon that patch, which seems to solve #16
Comment #21
mpotter CreditAttribution: mpotter commentedI don't see how the patch in #16 would have any effect (save immediately after deleting). Can somebody confirm if this is still happening in the latest 1.x-dev version of Features? At this point I cannot reproduce.