Field Feeds Presave Not Importing User Fields

Can you tell me what kind of field you're importing into? This looks like a bug with a mapper.

Can you debug what that field value is? That could help us figure out the problem.

Those are most likely the same issue.

What I meant was, can you find out the actual field value that's causing the issue?

This should log something to see what the problem is.

I'm seeing exactly same error message with the current dev (July 13). Shane, could you elaborate on what exactly did you do to solve the issue?

@minff, can you try applying the patch in #8, re-running the import, and telling me what shows up in the logs?

Actually, my problem solved itself, I think. Stopping the current import (I have one that runs all the time) and starting it again made the error disappear, just like Shane's experience.

The problem popped up again and after a long debugging process I managed to find the culprit.

The problem: fields for some (not all) imported commerce products (through entity processor in my case) were not imported and left blank, resulting in EntityMalformedException errors (and all kinds of others) in watchdog.

The debugging code shared in #8 as a patch showed that when the custom field mappings reached field.inc, they were presented as regular strings, not properly structured arrays (with language and keys and all that). That problem came from function mapToTarget() in FeedsProcessor.inc, where target is set just as it is if no callback function is identified. And callback for custom fields is not identified if info about target fields is not passed to that function through getCachedTargets(). Skipping some steps, it boiled down to getMappingTargets() function where entity processor was using the following code:

    // Let other modules expose mapping targets.
    self::loadMappers();
    $entity_type = $this->entityType();
    $bundle = $this->config['product_type'];
    drupal_alter('feeds_processor_targets', $targets, $entity_type, $bundle);

When I replaced it with getHookTargets() function as the node processor in Feeds dev does, errors disappeared and fields were mapped correctly. So, the replacement code is this:

    $this->getHookTargets($targets);

Since it is not directly concerned with the core Feeds module, I'm sharing it just to inform any others out there struggling with similar problems.

@minff
Did you had the issue with both the Commerce Product processor from Commerce Feeds and the Feeds entity processor or only the entity processor? I see you reported an issue for the entity processor: #2540146: Use getHookTargets in getMappingTargets, but not for Commerce Feeds. It looks like that they both need to be updated, though.

Indeed, I run into the same problem with Commerce Feeds, but I started with a thorough debugging when I had switched already to entity processor. The solution might be the same, but I cannot confirm that.

Oh, it seems that somebody beat me to it just some hours ago in Commerce Feeds issue queue, pointing to the same solution: https://www.drupal.org/node/1998222#comment-10154356

I commented on the commerce_feeds issue.

getHookTargets() shouldn't be required, nice to use, but it should be backwards compatible. The problem with commerce_feeds is that it's using feeds_alter() which was deprecated years ago, and never really worked correctly.

As to why the feeds_entity_processor is broken, not sure yet.

Thanks for debugging this!

Well, the root cause is not calling it one way or another, but the problem is that entity processor does not invoke all functions providing targets (incl. custom fields). Code behind FeedsProcessor->getHookTargets():

    self::loadMappers();
    $entity_type = $this->entityType();
    $bundle = $this->bundle();
    $targets += module_invoke_all('feeds_processor_targets', $entity_type, $bundle); // This is the important bit
    drupal_alter('feeds_processor_targets', $targets, $entity_type, $bundle);

This is how FeedsEntityProcessor->getMappingTargets() did it until my fix:

    self::loadMappers();
    $type = $this->entityType();
    $bundle = $this->bundle();
    drupal_alter('feeds_processor_targets', $targets, $type, $bundle);

And this is how the FeedsCommerceProductProcessor->getMappingTargets() (Commerce Feeds DEV) does it:

    self::loadMappers();
    $entity_type = $this->entityType();
    $bundle = $this->config['product_type'];
    drupal_alter('feeds_processor_targets', $targets, $entity_type, $bundle);

They seem to call only on hooks, but not invoking the modules directly. I think – and my experience now confirms it – that adding the 4th line present in getHookTargets() to these contrib modules solves these issues some people are having with EntityMalformedException and other errors.

In #2584157: Missing mapping targets in the UI for contrib processors I fixed a bug that caused the getHookTargets() method to be not fully backwards compatible. I also changed the Feeds entity processor to use this method in #2581911: Missing mappings.

These changes may render this issue obsolete. Is that the case or is this still an issue on the latest dev of Feeds?

Drupal 7 reached end of life and the D7 version of Feeds is no longer being developed. To keep the issue queue focused on supported versions, we’re closing older D7 issues.

If you still have questions about using Feeds on Drupal 7, feel free to ask. While we won’t fix D7 bugs anymore, we’re happy to offer guidance to help you move forward. You can do so by opening (or reopening) a D7 issue, or by reaching out in the #feeds channel on Drupal Slack.

If this issue is still relevant for Drupal 10+, please open a follow-up issue or merge request with proposed changes. Contributions are always welcome!