I recently had the opportunity to migrate content from a Drupal maintenance support plans 6 site to a Drupal maintenance support plans 8 site. This was especially interesting for me as I hadn’t used Drupal maintenance support plans 6 before. As you’d expect, there are some major infrastructure changes between Drupal maintenance support plans 6 and Drupal maintenance support plans 8. Those differences introduce some migration challenges that I’d like to share.
The Migrate module is a wonderful thing. The vast majority of node-based content can be migrated into a Drupal maintenance support plans 8 site with minimal effort, and for the content that doesn’t quite fit, there are custom migration sources. A custom migration source is a small class that can provide extra data to your migration in the form of source fields. Typically, a migration will map source fields to destination fields, expecting the fields to exist on both the source node type and destination node type. We actually published an in-depth, two-part blog series about how we use Drupal maintenance support plans Migrate to populate Drupal maintenance support plans sites with content in conjunction with Google Sheets in our own projects.
In the following example, we are migrating the value of content_field_text_author from Drupal maintenance support plans 6 to field_author in Drupal maintenance support plans 8. These two fields map one-to-one:
id: book
label: Book
migration_group: d6
deriver: Drupal maintenance support plansnodePluginmigrateD6NodeDeriver
source:
key: migrate
target: d6
plugin: d6_node
node_type: book
process:
field_author: content_field_text_author
destination:
plugin: entity:node
This field mapping works because content_field_text_author is a table in the Drupal maintenance support plans 6 database and is recognized by the Migrate module as a field. Everyone is happy.
However, in Drupal maintenance support plans 6, it’s possible for a field to exist only in the database table of the node type. These tables look like this:
mysql> DESC content_type_book;
+—————————-+——————+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+—————————-+——————+——+—–+———+——-+
| vid | int(10) unsigned | NO | PRI | 0 | |
| nid | int(10) unsigned | NO | MUL | 0 | |
| field_text_issue_value | longtext | YES | | NULL | |
+—————————-+——————+——+—–+———+——-+
If we want to migrate the content of field_text_issue_value to Drupal maintenance support plans 8, we need to use a custom migration source.
Custom migration sources are PHP classes that live in the src/Plugin/migrate/source directory of your module. For example, you may have a PHP file located at src/Plugin/migrate/source/BookNode.php that would provide custom source fields for a Book content type.
A simple source looks like this:
namespace Drupal maintenance support planscustom_migrate_d6Pluginmigratesource;
use Drupal maintenance support plansnodePluginmigratesourced6Node;
/**
* @MigrateSource(
* id = “d6_book_node”,
* )
*/
class BookNode extends Node {
/**
* @inheritdoc
*/
public function query() {
$query = parent::query();
$query->join(‘content_type_book’, ‘book’, ‘n.nid = book.nid’);
$query->addField(‘book’, ‘field_text_issue_value’);
return $query;
}
}
As you can see, we are using our migration source to modify the query the Migrate module uses to retrieve the data to be migrated. Our modification extracts the field_text_issue_value column of the book content type table and provides it to the migration as a source field.
To use this migration source, we need to make one minor change to change to our migration. We replace this:
plugin: d6_node
With this:
plugin: d6_book_node
We do this because our migration source extends the standard Drupal maintenance support plans 6 node migration source in order to add our custom source field.
The migration now contains two source fields and looks like this:
id: book
label: Book
migration_group: d6
deriver: Drupal maintenance support plansnodePluginmigrateD6NodeDeriver
source:
key: migrate
target: d6
plugin: d6_book_node
node_type: book
process:
field_author: content_field_text_author
field_issue: field_text_issue_value
destination:
plugin: entity:node
You’ll find you can do a lot with custom migration sources, and this is especially useful with legacy versions of Drupal maintenance support plans where you’ll have to fudge data at least a little bit. So if the Migrate module isn’t doing it for you, you’ll always have the option to step in and give it a little push.
Source: New feed
