Quite frequently, hooks defined by other modules firing during migration (as a result of node_save(), user_save(), etc.) cause various problems - most often it's simply a performance impact (use the timer instrument to identify these), but sometimes it's actually dangerous (such as sending email notifications). With Migrate 2.6 and later, hooks belonging to other modules can be disabled in the migration configuration.

DESCRIPTION

This module converts references fields (from references module) to entity reference fields. A batch task will be issued (per field) to create a temporary table, store the reference values, delete the reference field, create a new
entity reference field, and copy over the values from the temporary table.

USAGE

There are 2 possible ways to convert fields:

USER INTERFACE

Go to admin/content/migrate-references, select the fields you wish to convert, and click confirm.

DRUSH

Type 'drush entityreference-migrate-references' (or 'drush emr') to convert all fields. You may provide a field machine name as an argument to convert on a field-by-field basis.

PRE-CONVERSION TASK LIST

Before starting any conversion, there are a few recommended tasks.

FIELDS

1. Create a where-used list of fields, widgets and formatters, using:
   • core: /admin/reports/fields
   • contrib: Field Info

VIEWS

1. Create a where-used list of fields, filter criteria, sort criteria, contextual filters, using:
   • views: /admin/reports/fields/views-fields

This page has been written to be up-to-date with Organic Groups 7.x-2.2

Organic groups 7.x-2.x is built to work with the Migrate module (https://drupal.org/project/migrate). No additional modules is needed.

Groups

Create a migration class for your group entity or content type as you normally would using MigrateDestinationNode or your own MigrateDestinationEntity/MigrateDestinationEntityAPI subclass. On this entity you will have two fields which are related to Organic Groups, normally named group_group and og_roles_permissions.

• group_group takes a value 0 or 1. 1 means that the node or entity is a group.
• og_roles_permissions also takes a value 0 or 1. In this case, 1 means that the group may define its own roles and permissions.

In case you are happy with the default values for these fields applying to all your imported groups, you don't have to do anything. Your migration will just work. However, it is possible to change the default values:

    // Organic Groups
    $this->addFieldMapping('group_group')->defaultValue(1);
    $this->addFieldMapping('og_roles_permissions')->defaultValue(0);

Group content

As explained at Why you should run migrations in Drush rather than the UI, drush is a faster and more robust means of running large migration operations than the web-based UI is. As of Migrate 2.6, it is possible (with some advanced server-side configuration) to start migration operations from the UI that will run in the background via drush on the server.

Configuring background operations

To enable background imports and rollbacks requires some configuration on the server side. The key element is letting the Migrate module know where the drush command resides on the server, so it can be run. This is done by setting the Drupal migrate_drush_path variable to the full path of the drush command on the server, either in settings.php:

$conf['migrate_drush_path'] = '/usr/bin/drush';

or by setting the variable using drush:

$ drush vset migrate_drush_path /usr/bin/drush

On a windows server the path of the drush command has to include 'drush.bat', e.g. like C:\ProgramData\Drush\drush.bat.

The contrib module Commerce Migrate provides a few destination classes that extend the Entity API destination class provided by Migrate Extras.

When declaring the destination map, use "commerce_product" as the entity type (which is defined by the Commerce module suite), and "my_product_type" as the bundle type.

The following class imports commerce products. "sku" and "commerce_price" mappings are relevant to products. In the following example, "my_product_type" is the machine name of the commerce product type (defined via UI config), "import_database" is the import database name (defined in settings.php), and "import_data" is the table in that database where the import data exists. In the source map, "ItemNumber" is the unique identifier column in the table.

<?php
class AseEndoMigration extends Migration {
/**
* Doc comment.
*/
public function __construct() {
parent::__construct();

// The defintion of the columns.
$columns = array(
'Category',
'Name',
'ItemNumber',
'Description',
'USRetailPrice',
);

// Entity type, and bundle.
$this->destination = new MigrateDestinationCommerceProduct('commerce_product', 'my_product_type');

// Select all endodontic products.

The following class was used to migrate taxonomy term images from Drupal 5's Taxonomy Image module into a proper Drupal 7 entity field. You'll want to adjust class and field names appropriately for your use case.

Note: Taxonomy Image in Drupal 5 did not make use of the files table, so you need to specify a path to your taxonomy images in the prepareRow() method.

<?php
class GWJTermImageMigration extends DrupalTerm5Migration {

public function __construct(array $arguments) {
$this->sourceFields['field_image'] = t('Constructed source image field');
$this->sourceFields['field_image:title'] = t('Constructed source image title field');
$this->sourceFields['field_image:alt'] = t('Constructed source image alt field');
$this->sourceFields['field_image:source_dir'] = t('Constructed source image source directory field');
$this->sourceFields['field_image:destination_dir'] = t('Constructed source image destination directory field');
$this->sourceFields['field_image:destination_file'] = t('Constructed source image destination file field');
parent::__construct($arguments);

$this->addFieldMapping('field_image', 'field_image');
$this->addFieldMapping('field_image:file_class')->defaultValue('MigrateFileUri');
$this->addFieldMapping('field_image:title', 'field_image:title')->defaultValue('');