Occasionally, we are encountering an issue where a feed import reverts the value of a field that is not a specified target. It goes like this:
1. Run the import, get a node with mapped targets
2. Change the value of an un-mapped target, body for example
3. Run the import again (scheduled imports once a day), mapped targets update, body field reverts to previous value (user's change is lost)
To solve this I can manually grab the change from the previous revision.
The problem occurs on our production site, but I am unable to get the problem to occur on our QA server or local development environment.
The environments are roughly the same (CentOS/RHEL 7, PHP 5.4) except the only difference on production is that the environment is load balanced, has a galera cluster and memcached installed. So I have a sneaking suspicion that this might have to do with memcache or galera.
In an unrelated issue, I did apply this patch to take care of some over-aggressive hash skipping in Entity Reference's feeds integration: https://www.drupal.org/node/2108169
Comment | File | Size | Author |
---|---|---|---|
myfeed.php.txt | 3.11 KB | cdmo |
Comments
Comment #2
MegaChriz CreditAttribution: MegaChriz as a volunteer commentedI don't see anything special in the posted importer configuration code that could affect the body field.
Possible causes I can think of:
Comment #3
cdmo CreditAttribution: cdmo commentedThanks for the quick reply.
I'm not using any content workflow module *except* for a very low fuss rule that trips a boolean field for 'Needs Review" any time a page is edited. I guess it's possible that rule could be the culprit, I'll look more into it.
Item 2 your suggesting is intriguing. I'd say it is unlikely, but it could be possible and would explain the issue.
I'm worried about the galera piece in regards to item 2. For example one of the databases not being synced properly and then database 1 and database 2 are different, for this example lets say db 2 just recorded a change to the body field. Then database 1 is tasked with running the import but it doesn't have the change made to the body in db2 (maybe due to bad configuration of the cluster).
Thanks again.
Comment #4
MegaChriz CreditAttribution: MegaChriz as a volunteer commented@cdmo
Your issue could be language related. I just discovered that if the language on the processor settings of the importer does not match the language of the nodes to update, then Feeds modifies the language of the updated nodes.
See also #3023511: Import erases body, summary, date/time, and other fields when updating existing nodes..
Assuming the solution provided at the other issue, fixes this issue as well, I set this issue to "fixed". If you still encounter this issue, even after following the instructions in the other issue, then reopen this issue if you still seeking for a solution.
Comment #5
cdmo CreditAttribution: cdmo commentedThis problem has been resolved yes, thanks for checking in. Unfortunately I can't remember what the fix was. My poor brain!