I'm trying to create a migration of additional data into products in the site after content was pulled in by the commerce migrate module (this is based off changing the system of record documentation that you provided at http://drupal.org/node/1117454). By default, the commerce migrate module also pulls in and copies over an image field from D6 ubercart. However, the issue that I run into is that if I try to run the migration, it actually fails and the error that I end up with is:
is_file() expects parameter 1 to be string, array given File /Users/ashokmodi/Sites/de_d7/sites/all/modules/migrate/plugins/destinations/fields.inc, line 400
To note, I initially had a set of additional image fields coming in as part of my migration but I removed that portion of the code so my migration would just handle text fields and I still run into this issue. When I look at what happens in the buildFileArray() function, I see that a file array gets passed in and it is of the original image field from ubercart. I've not tried to replicate the issue with node handlers but it seems like the node object gets created in full and any field that is a file gets buildfilearray run on regardless of whether or not it is specified as a mapping in the migration. This probably the wrong way to approach it but for now, I added in the following into the code before line 400:
// This field has been previously processed; do not do anything more with it.
if (is_array($full_path)) {
return;
}
And that worked. I'm not sure if this is right but atleast for the secondary migration, that seems to have done the trick. Not sure what happens in the case of a migration that relies on highwater for updates, however.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | hitachi_hta_migration.migrate.inc_.tar_.gz | 1.28 KB | jantoine |
Comments
Comment #1
mikeryanDon't have time to construct a test case, but I can see what's happening - the entity prepare() system assumes it's receiving raw values rather than field arrays (since its primary purpose is constructing such arrays) - looking at the code, I'm surprised there aren't more problems with other kinds of fields. This will take some investigation...
Comment #2
btmash commentedHmm, so are you saying that these may be a problem with how the fields are being built out or this is strictly a file issue?
One thing I realized after my original post is that I had actually done a non system-of-record migration last year that involved highwater and there weren't any issues then; so it may be limited strictly to the sytem-of-record case.
Comment #3
jantoine commentedI am running into the problem as well with a custom migration of images from the D6 Taxonomy Image module to the core Fields API. I have set systemOfRecord to Migration::DESTINATION as I am upgrading existing taxonomy terms. I am passing the 'path' field as the 'source_field' for the 'source_path' argument. This is choking on line 455 of the fileds.inc file in the buildFileArrary() function. The $value param holds the correct path to the file, but the 'source_path' argument is still an array containing the 'source_field' => 'path' array. This causes it to choke as a 'source_path' (an array) is passed to the rtrim() function.
Similar to BTMash, I added the following check to the if statement on line 449:
I'm not sure what implications this has for other configurations, but it is working for mine.
Comment #4
mikeryanThis will take some thought, it's a fundamental flaw with field handlers in the context of a DESTINATION migration. We need some way to prevent the field handlers from doing anything when the field array is already built - maybe it's a simple fix in migrate_field_handler_invoke_all(), maybe not...
Comment #5
mikeryanI haven't figured out a way to reproduce this - can someone having this trouble give some more details on their migration? Destination, field mappings, ...?
Thanks.
Comment #6
jantoine commentedI was having this issue with the attached migration file.
Comment #7
mikeryanDon't have time to review it right now - setting to active so I'll get back to it.
Thanks.
Comment #8
mikeryanLooks like a typo, you have
It should be
Comment #9
jantoine commented@mikeryan,
Thanks for looking into this. The typo was definitely causing the issue I was seeing. Thanks for pointing this out. Having gone back and read through the issue summary, I believe that my issue is unrelated to the original as I am migrating images into an empty file field and BTMash's issue seems to originate with file fields that have data associated with them.
Comment #10
mikeryanOK, so at the moment there are no reproducible instances of the original problem here - if someone comes up with one, please reopen.
Comment #11
btmash commentedI should have gotten back on this sooner and I apologize for that (I had found a workaround for this but still...my bad). I'll see if the issue still persists and if it does, then I'll post back. Keeping it closed but assigning to me so I remember to tackle it at some point.