Migrate Process Plugin Examples

Migrate process plugins are chainable methods for manipulating data during a migration.  Here are some common sequences of process plugins.  These examples are not specific to Migration Tools.   Most are just useful combinations of what process plugins are provided by Migrate core and Migrate Plus

Address Process Example

The fields from the address module are sometimes troublesome in the data they need.

# Assumes the destination field name is "field_address", adjust to suit your field names. 
process:
  field_address/country_code:
    plugin: default_value
    source: {SOURCE FIELD}
    default_value: US
  field_address/langcode:
    plugin: default_value
    default_value: en
  field_address/locality: {SOURCE FIELD}
  # Assumes data is in two letter State codes (ie. NY, FL, AZ).
  field_address/administrative_area: {SOURCE FIELD}
  field_address/postal_code: {SOURCE FIELD}
  # Converting data from multiple source fields for street address into one can be tricky. 
  # Here is one example that would take up to three entries and concatenate them into one.
  field_address/address_line1:
    -
      ## Make an array of the three sources.
      plugin: get
      source:
        - {SOURCE FIELD 1} # street address
        - {SOURCE FIELD 2} # suite number
        - {SOURCE FIELD 3} # PO box
    -
      # Get rid of any empty fields from the array.
      plugin: callback
      callable: array_filter
    -
      # Convert them from an array into multiple values so they can be trimmed.
      plugin: multiple_values
    -
      # Remove any extraneous trailing or leading spaces.
      plugin: callback
      callable: trim
    -
      # Concatenate any values with comma and space.
      plugin: concat
      delimiter: ', '
  

Term Entity Reference with Auto-generation Under a Parent

Sometimes it it not enough just to create a term that does not exist, sometimes it has to be created under the proper parent. Here is an example of how to define the parent.

process:
# Pseudo fields have no real destination but can be processed the same way.
  pseudo_field_parent:
    -
      plugin: entity_lookup
      entity_type: taxonomy_term
      value_key: name
      bundle_key: vid
      bundle: the_taxonomy_bundle_to_search
      source: source_parent_name_to_look_up 
    -
      plugin: skip_on_empty
      method: row
      message: 'Entity lookup for Parent found nothing.'

field_taxonomy_entity_field_name:
    -
      plugin: entity_generate
      entity_type: taxonomy_term
      source: source_term_name_to_look_up 
      ignore_case: true
      value_key: name
      bundle_key: vid
      bundle: the_taxonomy_bundle_to_search
      values:
        parent: '@pseudo_field_parent'

Revisions Process Example

Getting revisions to show correctly on migrations that are run repeatedly to update content can be a bit tricky.  The following process plugin example should get them working

process:
  changed:
    plugin: callback
    callable: time
  new_revision:
    plugin: default_value
    default_value: true
  revision_default:
    plugin: default_value
    default_value: true
  revision_log:
    plugin: default_value
    default_value: "Update of status by migration."
  revision_timestamp:
    plugin: callback
    callable: time
  # The user id of any user to be associated with the revision.
  revision_uid:
    plugin: default_value
    default_value: 1317
  uid:
    plugin: default_value
    default_value: 1317

And then in the overwrite properties  you will want to set these fields so they get altered by the migration on repeated runs.

destination:
 overwrite_properties:
  - changed
  - new_revision
  - revision_default
  - revision_log
  - revision_timestamp
  - revision_uid
  - uid