Maybe this is documented somewhere and I missed it. Correct me if I'm wrong, but it seems like a glaring bug if Migration::prepareRow() is called long after MigrateFieldHandler::prepare() which is implemented by relevant field handlers to react on row data and populate subfield values.

It seems like both MigrateDestination and MigrateFieldHandler should have an additional prepareRow() method that is invoked after Migration::prepareRow() so that MigrateFieldHandler can act on data prepared in Migration::prepareRow(). This solution would allow relevant field handlers to implement prepareRow() instead of prepare() while allowing migrations to prepare data for subfields.

I've waisted hours tracing this down while developing a custom field handler and had to resort to altering the source data instead of preparing the data in the migration as would be preferable.

If this "works as designed" please let me know and I'll convert this ticket into a Feature request or Documentation task.

I can start work on a patch for this, but was hoping to get some feedback from others before starting the endeavor.

// The following does not work for ANY subfield regardless of the field type:

$this->addFieldMapping('field_destination:subfield', 'prepared_source_data');
...
public function prepareRow(&$row) {
  $this->prepared_source_data = 'Hello World'
}

Comments

lee20 created an issue. See original summary.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Murphysboro, IL, USA
CreditAttribution: mikeryan at Acquia commented
Category: Bug report » Support request
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

Actually, prepareRow() is called long before the prepare() functions.

I recommend replacing

public function prepareRow(&$row) {
  $this->prepared_source_data = 'Hello World'
}

with

public function prepareRow($row) {
  $row->prepared_source_data = 'Hello World';
}