Today we complete the user migration example. This time, we cover creation date, roles, and profile pictures and we are jumping straight to the process transformations in this entry.
Today we are going to learn how to migrate users into Drupal. The example code will be explained in two blog posts. In this one, we cover the migration of email, timezone, username, password, and status.
This example consists of two separate migrations. One to import taxonomy terms accounting for term hierarchy. And another to import into a multivalue taxonomy term field. Following this approach, any node and taxonomy term created by the migration process will be removed from the system upon rollback.
One of Drupal’s biggest strengths is its data modeling capabilities. You can break the information that you need to store into individual fields and group them in content types. Today we will learn about migration dependencies in Drupal.
We have already covered two of many ways to migrate images into Drupal. Today, we are going to perform an image migration that will clear after itself when it is rolled back. Note that in Drupal images are a special case of files. Even though the example will migrate images, the same approach can be used to import any type of file.
We have presented several examples as part of this migration blog post series. Today we are going to talk about what happens after import and rollback operations, how to recover from a failed migration, and some tips for writing definition files.
So far we have learned how to write basic Drupal migrations and use process plugins to transform data to meet the format expected by the destination. In the previous entry we learned one of many approaches to migrating images. In today’s example, we will change it a bit to introduce two new migration concepts.
Migrate process plugins transform data between source and destination. This gets more complicated for Drupal fields have multiple components. Today we will learn how to migrate into them and know which subfields are available.
Sometimes in a Drupal 7 to Drupal 8 migration we copy values verbatim from the source to the destination. Often, the data needs to be transformed to match the format expected by the destination. Today we will learn more about process plugins and how they work as part of the Drupal migration pipeline.
In the previous entry, we learned that the Migrate API is an implementation of an ETL framework. We also talked about the steps involved in writing and running migrations. Now, let’s write our first Drupal migration. We are going to start with a very basic example: creating nodes out of hardcoded data. For this, we assume a Drupal installation using the standard installation profile which comes with the Basic Page content type.