public function BeerTermMigration::__construct in Migrate 7.2

Same name and namespace in other branches

1. 6.2 migrate_example/beer.inc \BeerTermMigration::__construct()

General initialization of a Migration object.

Overrides BasicExampleMigration::__construct

File

migrate_example/beer.inc, line 82

A basic example of using the Migrate module to import taxonomy, users, nodes, and comments.

Class

BeerTermMigration

There are four essential components to set up in your constructor: $this->source - An instance of a class derived from MigrateSource, this will feed data to the migration. $this->destination - An instance of a class derived from…

Code

public function __construct($arguments) {
  parent::__construct($arguments);

  // Human-friendly description of your migration process. Be as detailed as
  // you like.
  $this->description = t('Migrate styles from the source database to taxonomy terms');

  // In this example, we're using tables that have been added to the existing
  // Drupal database but which are not Drupal tables. You can examine the
  // various tables (starting here with migrate_example_beer_topic) using a
  // database browser such as phpMyAdmin.
  // First, we set up a query for this data. Note that by ordering on
  // style_parent, we guarantee root terms are migrated first, so the
  // parent_name mapping below will find that the parent exists.
  $query = db_select('migrate_example_beer_topic', 'met')
    ->fields('met', array(
    'style',
    'details',
    'style_parent',
    'region',
    'hoppiness',
  ))
    ->orderBy('style_parent', 'ASC');

  // Create a MigrateSource object, which manages retrieving the input data.
  $this->source = new MigrateSourceSQL($query);

  // Set up our destination - terms in the migrate_example_beer_styles
  // vocabulary (note that we pass the machine name of the vocabulary).
  $this->destination = new MigrateDestinationTerm('migrate_example_beer_styles');

  // Create a map object for tracking the relationships between source rows
  // and their resulting Drupal objects. We will use the MigrateSQLMap class,
  // which uses database tables for tracking. Pass the machine name (BeerTerm)
  // of this migration to use in generating map and message table names.
  // And, pass schema definitions for the primary keys of the source and
  // destination - we need to be explicit for our source, but the destination
  // class knows its schema already.
  $this->map = new MigrateSQLMap($this->machineName, array(
    'style' => array(
      'type' => 'varchar',
      'length' => 255,
      'not null' => TRUE,
      'description' => 'Topic ID',
    ),
  ), MigrateDestinationTerm::getKeySchema());

  // Assign mappings TO destination fields FROM source fields. To discover
  // the names used in these calls, use the drush commands
  //  drush migrate-fields-destination BeerTerm
  //  drush migrate-fields-source BeerTerm
  // or review the detail pages in the UI.
  $this
    ->addFieldMapping('name', 'style');
  $this
    ->addFieldMapping('description', 'details');

  // Documenting your mappings makes it easier for the whole team to see
  // exactly what the status is when developing a migration process.
  $this
    ->addFieldMapping('parent_name', 'style_parent')
    ->description(t('The incoming style_parent field is the name of the term parent'));

  // Mappings are assigned issue groups, by which they are grouped on the
  // migration info page when the migrate_ui module is enabled. The default
  // is 'Done', indicating active mappings which need no attention. A
  // suggested practice is to use groups of:
  // Do Not Migrate (or DNM) to indicate source fields which are not being
  //  used, or destination fields not to be populated by migration.
  // Client Issues to indicate input from the client is needed to determine
  //  how a given field is to be migrated.
  // Implementor Issues to indicate that the client has provided all the
  //  necessary information, and now the implementor needs to complete the
  //  work.
  $this
    ->addFieldMapping(NULL, 'hoppiness')
    ->description(t('This info will not be maintained in Drupal'))
    ->issueGroup(t('DNM'));

  // Open mapping issues can be assigned priorities (the default is
  // MigrateFieldMapping::ISSUE_PRIORITY_OK). If you're using an issue
  // tracking system, and have defined issuePattern (see BasicExampleMigration
  // above), you can specify a ticket/issue number in the system on the
  // mapping and migrate_ui will link directly to it.
  $this
    ->addFieldMapping(NULL, 'region')
    ->description('Will a field be added to the vocabulary for this?')
    ->issueGroup(t('Client Issues'))
    ->issuePriority(MigrateFieldMapping::ISSUE_PRIORITY_MEDIUM)
    ->issueNumber(770064);

  // It is good practice to account for all source and destination fields
  // explicitly - this makes sure that everyone understands exactly what is
  // being migrated and what is not. Also, migrate_ui highlights unmapped
  // fields, or mappings involving fields not in the source and destination,
  // so if (for example) a new field is added to the destination typ it's
  // immediately visible, and you can decide if anything needs to be
  // migrated into it.
  $this
    ->addFieldMapping('format')
    ->issueGroup(t('DNM'));
  $this
    ->addFieldMapping('weight')
    ->issueGroup(t('DNM'));
  $this
    ->addFieldMapping('parent')
    ->issueGroup(t('DNM'));

  // We conditionally DNM these fields, so your field mappings will be clean
  // whether or not you have path and/or pathauto enabled.
  $destination_fields = $this->destination
    ->fields();
  if (isset($destination_fields['path'])) {
    $this
      ->addFieldMapping('path')
      ->issueGroup(t('DNM'));
    if (isset($destination_fields['pathauto'])) {
      $this
        ->addFieldMapping('pathauto')
        ->issueGroup(t('DNM'));
    }
  }
}