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

CommentFileSizeAuthor
myfeed.php.txt3.11 KBcdmo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cdmo created an issue. See original summary.

MegaChriz’s picture

I don't see anything special in the posted importer configuration code that could affect the body field.

Possible causes I can think of:

  1. A module acts on a node update and accidently reverts some field values. Are you using any content moderation modules, like the Workflow module or the Workbench Moderation module? Someone posted an issue with the Workbench Moderation module: #2820480: Mapper for Updated date (changed) doesn't always work.
  2. Not likely, but possible: the body field is edited around the same time that an import runs.
cdmo’s picture

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

MegaChriz’s picture

Status: Active » Fixed

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

cdmo’s picture

This problem has been resolved yes, thanks for checking in. Unfortunately I can't remember what the fix was. My poor brain!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.