Upgrade Your Drupal Skills
We trained 1,000+ Drupal Developers over the last decade.
See Advanced Courses NAH, I know EnoughGetting on board with Drupal-to-Drupal migrations
As a Drupal newbie, I started working on migrating data from a Drupal 7 project to a Drupal 8 project. I’ve put together how-to migrate your data, especially the complex fields. Our project uses the Migrate API, which is part of the Drupal core.
Discover more about the service CMS our digital agency has to offer for you.
You can generate migrations for your Drupal 7 content and configuration using the Migrate Drupal module. The Migrate Drupal module is based on the Migrate API.
The generated content migrations work fine for your standard fields from the field module but Migrate API doesn’t provide out of the box migrate plugins for custom fields. A way to migrate them is by customizing the migration.
I had to write a custom migration for the domain access records. The domain access module manages access for nodes and users on multiple domains.
The challenge for those records was that they’re stored completely differently in Drupal 7. The Migrate API can’t fetch their data out of the box into a row. For less complex fields you could implement a custom process plugin. In this, you’d hook yourself into the process of a migration from a single field. There, you can transform your data as needed, such as filtering, mapping, or generally transforming values.
Matching data structures
To migrate complex data from source to destination it is often helpful to model their relationship in an entity relation diagram.
As you can see in the following picture Drupal 8 splits the fields for the domain access records into separate tables while Drupal 7 stores multiple fields in one table.
Extending a migration plugin
Existing plugins can be extended with additional data through protected and public methods. The Drupal\migrate\Row
class has a method setSourceProperty()
which allows you to add properties on the source row. Afterwards, you can access the new property in your migration YAML file in the same format as standard fields from the field module.
field_YOUR_CUSTOM_FIELD:
-
plugin: sub_process
source: ADDED_SOURCE_PROPERTY
process:
ID_XY: PROPERTY_ATTRIBUTE
To shorten the feedback loop while developing use this drush command:drush mim migration_id --limit=1 --idlist=YOUR_ID --update
With the combination of --limit
and --idlist
only the rows listed in --idlist
are being migrated and it stops after reaching the limit of --limit
.
Do you need to migrate data into Drupal? I learned that going through the following steps is helpful:
- Check if there’s a migration template for your case. These exist for nearly all sources with relevant plugins. Generate them automatically with Migrate Drupal for Drupal-to-Drupal migrations.
- Get yourself an overview of the data structure for the more complex fields. If Migrate API doesn’t provide a plugin that contains the field data in its source row, implement a custom migration, or extend an existing one.
- Do you have to deal with multiple field values? Check out the SubProcess plugin.
- In a custom process plugin, the properties are accessible from the fetched row. That’s how you’re able to filter, map, or transform those properties as you like.
About Drupal Sun
Drupal Sun is an Evolving Web project. It allows you to:
- Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
- Facet based on tags, author, or feed
- Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
- View the entire article text inline, or in the context of the site where it was created
See the blog post at Evolving Web