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

bob.hinrichs created an issue. See original summary.

bob.hinrichs’s picture

Issue summary: View changes
djdevin’s picture

I can also confirm this happening with IEF.

huzooka’s picture

Project: Location Migration » Inline Entity Form
Version: 1.0.x-dev » 8.x-1.x-dev

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

geek-merlin’s picture

geek-merlin’s picture

Status: Active » Postponed (maintainer needs more info)

Too many migration issues, many of which look overlapping or duplicate.
Postponing on parent issue.

anybody’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

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