Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#8 | feeds-debug-2509444-8.patch | 677 bytes | twistor |
#2 | feeds-skip-invalid-fields-2509444-1.patch | 557 bytes | twistor |
Comments
Comment #1
Shane Birley CreditAttribution: Shane Birley commentedData 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.
Comment #2
twistor CreditAttribution: twistor as a volunteer commentedCan you tell me what kind of field you're importing into? This looks like a bug with a mapper.
Comment #3
Shane Birley CreditAttribution: Shane Birley commentedMost 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.
Comment #4
Shane Birley CreditAttribution: Shane Birley commentedI applied the above patch and that seemed to fix the problem but it introduced this one:
And I failed to mention that three of the fields are taxonomy fields. D'oh.
Comment #5
twistor CreditAttribution: twistor as a volunteer commentedCan you debug what that field value is? That could help us figure out the problem.
Comment #7
Shane Birley CreditAttribution: Shane Birley commentedLet me dig into it.
Here is the full error message I just generated.
I also noted this one.
Repeated for each failed field.
Comment #8
twistor CreditAttribution: twistor as a volunteer commentedThose 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.
Comment #9
Shane Birley CreditAttribution: Shane Birley commentedI 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:
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.
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.
Comment #10
Shane Birley CreditAttribution: Shane Birley commentedAnd 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.
Comment #11
minff CreditAttribution: minff commentedI'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?
Comment #13
twistor CreditAttribution: twistor as a volunteer commented@minff, can you try applying the patch in #8, re-running the import, and telling me what shows up in the logs?
Comment #14
minff CreditAttribution: minff commentedActually, 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.
Comment #15
minff CreditAttribution: minff commentedThe 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:
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:
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.
Comment #16
MegaChriz CreditAttribution: MegaChriz as a volunteer commented@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.
Comment #17
minff CreditAttribution: minff commentedIndeed, 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.
Comment #18
minff CreditAttribution: minff commentedOh, 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
Comment #19
twistor CreditAttribution: twistor as a volunteer commentedI 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!
Comment #20
minff CreditAttribution: minff commentedWell, 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():
This is how FeedsEntityProcessor->getMappingTargets() did it until my fix:
And this is how the FeedsCommerceProductProcessor->getMappingTargets() (Commerce Feeds DEV) does it:
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.
Comment #21
MegaChriz CreditAttribution: MegaChriz at WebCoo commentedIn #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?