I cannot determine which module is buggy, but the inline_entity_form module has a MigrationHelper that performs this:
$migration['process']['options/type']['type']['map'] = array_merge($migration['process']['options/type']['type']['map'], $addition);
The formatting of the d7_entity_location_field_widget options/type parameter is a string : " 'options/type': widget_type' " which creates this error: 'Cannot use string offset as an array'
I have searched code for examples of your configuration and cannot find any, so am wondering if this is a bug in your code; or does it mean that the other module's code assumes an array where it is not required?
In core, I see many with options/type as '@type'.
Comments
Comment #2
bob.hinrichs commentedComment #3
djdevinI can also confirm this happening with IEF.
Comment #4
huzookaThis is an Inline Entity Form issue: IEF does not checks if there is a corresponding destination property, nor the key of the process, nor whether the process it thinks it alters is a
static_map.It just assumes that every migration plugin definition which uses a field instance source plugin (or a plugin which extends that source plugin) has the same structure what the d7_field_instance plugin definition has in Drupal core.
Comment #5
geek-merlinComment #6
geek-merlinToo many migration issues, many of which look overlapping or duplicate.
Postponing on parent issue.
Comment #7
anybodyDoing some cleanup as suggested in the parent issue: Closing this as duplicate of #3208818: Migration Error: Cannot use string offset as an array in MigrationHelper.php on line 53 as the other issue reports the same bug but has a patch already.