Last updated November 9, 2012. Created by mikeryan on October 22, 2012.
Edited by jaspher. Log in to edit this page.
The migrate_d2d classes can be used as-is for migrating core data (e.g., user email, username, password, created date, etc.) with sensible defaults, but what about custom fields?
Suppose in your legacy system you had field_published on your article nodes, and in the new D7 system the equivalent field is field_published_date. You can map these fields by implementing a custom class overriding the provided node class and adding the mapping:
<?php
class ExampleArticleMigration extends DrupalNode6Migration {
public function __construct(array $arguments) {
parent::__construct($arguments);
$this->addFieldMapping('field_published_date', 'field_published');
}
}
?>To make use of your custom class, pass its name rather than DrupalNode6Migration when registering your classes:
<?php
Migration::registerMigration('ExampleArticleMigration',
$article_node_arguments['machine_name'], $article_node_arguments)
?>Another common use case for overriding migration classes is modifying the base query. Each of the migrate_d2d classes has a query() method, returning the query object used to pull source data. By doing this rather than hard-coding the query into the constructor, you have the opportunity to customize the query for your application:
<?php
class ExampleUserMigration extends DrupalUser6Migration {
protected function query() {
// Get the default query (all rows in the users table other than uid 1)
$query = parent::query();
// Exclude test accounts
$query->condition('name', 'test-%', 'LIKE');
// Add fields from a custom table
$query->innerJoin('myextradata', 'd', 'u.uid=d.uid');
$query->fields('d', array('favorite_food', 'favorite_song'));
return $query;
}
}
?>