Migrate provides MigrateDefaultFieldHandler, which handles most fields pretty well. However, one oddity that I haven't quite figured out a reason for is that in order to set subfields (individual parts of a field), you have to pass arguments like this:

<?php
// Example from the Name module.
$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, additional components must be passed as arguments.
$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');
?>

This is really ungainly- for instance, you have to add the hackish dummy mappings at the end to stop the field from getting flagged as unmapped.

Why can't we simply map subfields directly, like so:

<?php
$this->addFieldMapping('field_name:given', 'profile_first_name');
$this->addFieldMapping('field_name:family', 'profile_last_name');
// etc...
?>

Having to use arguments instead of this relatively simple mapping is counterintuitive.

CommentFileSizeAuthor
#4 migrate-2223095-4.patch1.55 KBDane Powell
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dane Powell’s picture

Issue summary: View changes
Dane Powell’s picture

Apparently I've overlooked something, because I just tested this and it turns out you can map directly to field parts / subfields.

Maybe the problem here is just a lack of documentation. I think we should add a docblock to MigrateDefaultFieldHandler better describing how to map field parts like this, and if there's any other user documentation out there, make sure it's up-to-date too.

Would you accept a patch for this?

13rac1’s picture

The documentation seems straightforward: https://drupal.org/node/1133448

Subfields

When a destination field has options which can be set to control its behavior, or requires multiple pieces of data, these can be set using subfields. For example, to set a body and its summary:

    $this->addFieldMapping('body', 'body');
    $this->addFieldMapping('body:summary', 'excerpt');

The subfields are exposed on the migration detail pages just like regular fields, and all the power of field mappings can be applied to them.

A patch for code docs would be go though!

Dane Powell’s picture

Title: Why do multi-part fields use arguments instead of direct mapping? » Clarify docs around mapping of field parts
Category: Support request » Task
Status: Active » Needs review
FileSize
1.55 KB

Thanks for the link to that documentation. I think I was confused because all of the handlers I was dealing with were a bit older, and included outdated docs.

I updated the documentation page to clarify mapping subfields just a little. Here's a patch the cleans up the docs in code.

mikeryan’s picture

Component: Code » Documentation
Status: Needs review » Needs work

The subfield support has nothing specifically to do with MigrateDefaultFieldHandler, it's a general feature of field mappings (not field handlers) implemented in Migration::applyMappings(). Migration::addFieldMapping() would probably be the most useful place for code documentation, since that's the call where you actually use that syntax.

pifagor’s picture

Status: Needs work » Closed (outdated)