Unsure if this is related to what I am doing but I happened to notice this today:

Warning: Invalid argument supplied for foreach() in field_feeds_presave() (line 38 of /sites/all/modules/feeds/mappers/field.inc).

Fields are blanking or not being imported properly. Trying to determine that the data is clean... but worth mentioning.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Shane Birley’s picture

Data is clean. This seems to be very new and with the latest dev. The fields are getting skipped and not importing anything as each import request fails with this error.

twistor’s picture

Status: Active » Needs review
FileSize
557 bytes

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

Shane Birley’s picture

Most are text fields. There is one OG field (where the import is just the OG id) and Feeds Tamper is being used to generate the user name from first and last name text fields.

Not horribly complex but the configuration has been working great up until the latest dev release.

Shane Birley’s picture

I applied the above patch and that seemed to fix the problem but it introduced this one:

Warning: Invalid argument supplied for foreach() in taxonomy_field_presave

And I failed to mention that three of the fields are taxonomy fields. D'oh.

twistor’s picture

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

  • twistor committed 7704462 on 7.x-2.x
    Issue #2509444 by twistor: Field Feeds Presave Not Importing User Fields
    
Shane Birley’s picture

Let me dig into it.

Here is the full error message I just generated.

Warning: Invalid argument supplied for foreach() in taxonomy_field_presave() (line 1899 of /sites/all/modules/taxonomy/taxonomy.module).

I also noted this one.

Warning: Invalid argument supplied for foreach() in entity_metadata_field_property_get() (line 437 of /sites/all/modules/entity/modules/callbacks.inc).

Repeated for each failed field.

twistor’s picture

FileSize
677 bytes

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.

Shane Birley’s picture

I was beginning to think I was crazy but after about seven imports that produced nothing, I switched all fields. When I selected a different OG tid, I got this:

Missing bundle property on entity of type node.

This is the first I am seeing this error but somehow it is killing the import from actually completing. It views the correct data as the debug shows plain text without any weird characters, spaces, etc.

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7844 of /includes/common.inc).

Going to search around Drupal.org to see what situations cause this kind of problem. Any ideas on your end would be awesome.

Again, everything worked awesome for more than a year! Le sigh.

Shane Birley’s picture

And this is even stupider. I backed up the database, dropped it, reimported, and then made sure everything was set up again.

The import worked. It just... worked. No errors. No complaints. The fields updated the records from the tests I was doing. Running the latest dev from today.

minff’s picture

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?

twistor’s picture

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

minff’s picture

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.

minff’s picture

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.

MegaChriz’s picture

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

minff’s picture

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.

minff’s picture

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

twistor’s picture

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!

minff’s picture

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.

MegaChriz’s picture

Status: Needs review » Postponed (maintainer needs more info)

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?