Using migrate-7.x-2.6-RC1.

Motivation

Have you ever had a problem that certain rows in the CSV files used for Migration were empty, or didn't
need to be imported because of bogus data / empty fields?

Or maybe your CSV data is de-normalised and you want to skip certain rows that would
map to the same entities, but because of the skipping, your migration always shows
Incomplete Migration? Isn't that annoying? Especially if there are other dependent migrations
on the incomplete one, which won't run unless executed with --force.

In migrating taxonomy terms, the key is mapping the legacy vocabulary to the destination vocabulary. Note that up till now we've dealt with classes that you will generally instantiate once - this is our first example of classes you would instantiate multiple times, one for each vocabulary to migrate.

• source_vocabulary: The unique identifier of the legacy vocabulary (a machine name in Drupal 7, or a vid for earlier Drupal versions).
• destination_vocabulary: The unique machine name of the destination vocabulary.

<?php
// In this example, we're consolidating two legacy vocabularies into one
$photo_term_arguments = $common_arguments + array(
'machine_name' => 'ExamplePhotoTerm',
'description' => t('Import Drupal 6 photo terms into media terms'),
'source_vocabulary' => '3', // "Photo category" vocabulary
'destination_vocabulary' => 'media_category',
);
Migration::registerMigration('DrupalTerm6Migration',
$photo_term_arguments['machine_name'], $photo_term_arguments);

$video_term_arguments = $common_arguments + array(
'machine_name' => 'ExampleVideoTerm',
'description' => t('Import Drupal 6 video terms into media terms'),
'source_vocabulary' => '5', // "Video category" vocabulary
'destination_vocabulary' => 'media_category',
);

Some field types are more complex than others - in particular, they support a number of options controlling their behavior, or subfields providing additional data. These options or subfields can be mapped like regular fields - for example, to map the summary subfield of a text field:

$this->addFieldMapping('field_text', 'main_text');
$this->addFieldMapping('field_text:summary', 'teaser_text');

You can view all of the available subfields either in the migrate UI under the destination's tab for a specific migration or by using the drush migrate-fields-destination command. Just like regular field mappings if you leave a subfield un-mapped it will assume the Drupal default value for that column which varies depending on the type of field in question.

One common example is the 'language' subfield - this indicates the value of the field when requested for a given language and many fields have this additional data. The default is LANGUAGE_NONE ('und') - the default value when a specific language is not requested. If you were importing translated data you may want to set the appropriate language code with something like the following:

$this->addfieldMapping('field_name:language')->defaultValue('de');

Text fields