Improve and de-dupe migrate handler

+    return isset($return) ? $return : NULL;

Should be something like

+    return isset($return[$language]) ? $return : NULL;

If you want to insert some Name specific logic, (personally not fussed about this), these can be used.

$components = array_filter($field_info['settings']['components']);
$minimum_components = array_filter($field_info['settings']['minimum_components']);

I would not enforce $minimum_components, possibly unknown / non-existent in the data source. The data can be fixed when the entity is edited.

Filtering by allowed $components could prevent inserting data into the DB that is never accessible.

    // Setup the standard Field API array for saving.
    $components = array_filter($field_info['settings']['components']);
    foreach ($values as $value) {
      $item = array('given' => $value) + array_intersect_key($arguments, $field_info['columns']);
      $item = array_intersect_key($item, $components);
      if (array_filter($item)) {
        $return[$language][] = $item;
      }
    }

Finally, the arguments here only appear to support a singular name field item. What happens with multiple value fields?

Looking better :)

1) Tidied up the doc comment a bit.

/**
 * Allows using Name fields as Migrate destinations.
 *
 * The primary value passed to this field handler must be the 'given' component
 * and arguments are used to pass additional name components.
 *
 * Add the source field mappings to the argument array then add null mappings
 * to avoid having fields flagged as as unmapped.
 *
 * Example usage:
 * @code
 *   $arguments = array(
 *    'title' => array('source_field' => 'profile_title'),
 *    'middle' => array('source_field' => 'profile_middle_name'),
 *    'family' => array('source_field' => 'profile_last_name'),
 *   );
 *   // The given component should be passed in as the primary value.
 *   $this->addFieldMapping('field_name', 'profile_first_name')
 *        ->arguments($arguments);
 *   // Since the excerpt is mapped via an argument, add a null mapping so it's
 *   // not flagged as unmapped.
 *   $this->addFieldMapping(NULL, 'profile_title');
 *   $this->addFieldMapping(NULL, 'profile_middle_name');
 *   $this->addFieldMapping(NULL, 'profile_last_name');
 * @endcode
 *
 * @see MigrateDefaultFieldHandler
 */
class MigrateNameHandler extends MigrateFieldHandler {

2) I am not sure on functionality of the method, but this should be the same.

  public function fields($field_type, $field_instance) {
    $fields = _name_translations();
    // The given component is mapped directly to the field name,
    // so don't include it here among the sub-fields.
    unset($fields[$this->primaryColumn]);
    return $fields;
}

3) Since the code could potentially skip an item, this ensures that the returned delta values are consistent (although I think that cores field system does an array_values() here too)

- $return[$language][$delta] = $item;
+ $return[$language][] = $item;

4) I think that the delta variable can be moved into the for loop, as the delta value of the incoming values. 2 less loc

-    $delta = 0;
-    foreach ($values as $value) {
+    foreach ($values as $delta => $value) {
...
-      $delta++;

5) Without have a test environment, are the arguments in this structure? All I can say is "Ycks", but no comment on Migrate itself

// single
$arguments = array('given' => 'abc', ...)
// multiple
$arguments = array(array('given' => 'abc', ...), array('given' => 'dfg', ...));

I have one local migrate environment, but I can not test this as it is a XML feed that uses a JSON encoded request to get a node from the source and the MyClassXMLMigration::prepare($entity, $source_row) simply does this (without all of the special business logic and image / file field handing):

function MyClass extends XMLMigration {
  public function prepareRow($row) {
    $row->source_entity = MyClass::retriveNodeEntityRemoteServer($row->xml->nid);
  }

  public function prepare($entity, $source_row) {
    $entity->is_migrate_update = 1;
    if (isset($source_row->source_entity)) {
      foreach (field_info_instances($this->source_entity_type, $this->source_bundle) as $field_name => $instance) {
        if ($items = field_get_items($this->source_entity_type, $source_row->source_entity, $field_name)) {
          $field = field_info_field($field_name);
          $langcode = field_language($this->source_entity_type, $source_row->source_entity, $field_name);
          $entity->$field_name = array($langcode => $items);
        }
      }
    }
  }
}

The node entity has about 50 fields, 10 or so with no migrate support, but this just works and handling the business logic required where you have $source _entity and $destination_entity nodes is trivial ;)

I guess that you have come from using MigrateExtras, to just this?

So I wonder what will happen for users using just Name migrate and the Migrate class registry?

Maybe an empty update function that should (hopefully) force any caches to be flushed

/**
 * An empty update function to ensure that any Migrate
 * class caches are flushed.
 */
function name_update_7003() {}

[edit]
Actually looking at migrate_get_module_apis() [migrate 7.x-2.6-rc1], this is not needed :)

"totally fugly arguments structure" is by design from memory, I think I have seen these before :/

Happy to commit with #1 - #3

Nope, not sure. First time I saw this I thought ffs, not only do you need to know the field schema structure you need to know the wield mapping rules... maybe a work around for the migrate internals?

Can someone actively using a name migration actual confirm that this will not cause a fatal error due to a potential stale class registry please? I have no active migration environments to test atm :)

@Dane Powell
Does this require a change in anyones migration scripts? If so, a quick short summary would be good to go into the release page when the next one is rolled out would be fantastic!

@Alan D: I confirm that the patch from #16 does not cause any death screens. We actively use migrations with name fields, and they work only with this patch

I have used this patch for a simple use case and it works fine. I have a D7->D7 migration with 'given' and 'family' components.

So the source is a name field on Drupal. I first thought it would work like this for the 'given' component.

        // The given component should be mapped as the primary value.
        $this->addFieldMapping($field, $field);

...but had to do it like this.

        // The given component should be mapped as the primary value.
        $this->addFieldMapping($field, $field.':given');

Here's the whole field mapping section:

        // The given component should be mapped as the primary value.
        $this->addFieldMapping($field, $field.':given');
        // Now map other name components.
        $this->addFieldMapping($field.':family', $field.':family');

I am interested in this as well. How can I help testing/reviewing? Is there a migration example I could change according to my situation?

Could anyone explain why the 'given' part has been chosen as primary and not 'family'?

(Background: I noticed when migrating organizations in CRM Core that the family name is the one displayed. So at first sight, it looks like these contact types have been imported with an empty name. The workaround is to edit the name field and set family name hidden, given name visible).

Could this patch be included into the next version? Thank you!

I am working with CRM Core (specifically data imports via the Migration module).

This patch is necessary for CRM Core imports to run.

Importing data into CRM Core

leave the status, patch to be ported is for backporting committed patches to older versions

Such an old stale issue, but let me know if I need to add a change record or a simple note to the release page itself