# A "migration" is, in technical terms, a configuration entity which describes
# how to read source data, process it (generally by mapping source fields to
# destination fields), and write it to Drupal.
id: demo_uni_term

# A human-friendly description of the migration.
label: Taxonomy terms

# The machine name of the group containing this migration (which contains
# shared configuration to be merged with our own configuration here).
migration_group: demo_uni

# Every migration must have a source plugin, which controls the delivery of our
# source data. In this case, our source plugin has the name "demo_uni_term", which
# Drupal resolves to the PHP class defined in
# src/Plugin/pe_migrate/source/DemoUniTerm.php.
source:
  plugin: demo_uni_term

# Every migration must also have a destination plugin, which handles writing
# the migrated data in the appropriate form for that particular kind of data.
# Most Drupal content is an "entity" of one type or another, and we need to
# specify what entity type we are populating (in this case, taxonomy terms).
# Unlike the source plugin (which is specific to our particular scenario), this
# destination plugin is implemented in Drupal itself.
destination:
  plugin: entity:taxonomy_term

# Here's the meat of the migration - the processing pipeline. This describes how
# each destination field is to be populated based on the source data. For each
# destination field, one or more process plugins may be invoked.
process:
  # The simplest process plugin is named 'get' - it is the default plugin, so
  # does not need to be explicitly named. It simply copies the source value
  # (the 'name' field from the source database in this case) to the destination
  # field (the taxonomy term 'name' field). You can see we simply copy the
  # source 'description' field to destination 'description' field in the same way.
  name: name
  'description/value': description
  'description/format': format
  weight: weight
  vid: vocabulary_machine_name

  # Here's another new plugin - migration. When importing data from another
  # system, typically the unique identifiers for items on the destination side
  # are not the same as the identifiers were on the source side. For example, in
  # our style data the term names are the unique identifiers for each term,
  # while in Drupal each term is assigned a unique integer term ID (tid). When
  # any such items are referenced in Drupal, the reference needs to be
  # translated from the old ID ('ale') to the new ID (1). The migration
  # framework keeps track of the relationships between source and destination
  # IDs in map tables, and the migration plugin is the means of performing a
  # lookup in those map tables during processing.
  parent:
    plugin: migration
    # Here we reference the migration whose map table we're performing a lookup
    # against. You'll note that in this case we're actually referencing this
    # migration itself, since category parents are imported by the same
    # migration. This works best when we're sure the parents are imported
    # before the children, and in this case our source plugin is guaranteeing
    # that.
    migration: demo_uni_term
    # 'parent' is the parent reference field from the source data. The
    # result of this plugin is that the destination 'parent' field is populated
    # with the Drupal term ID of the referenced style (or NULL if parent
    # was empty).
    source: parent
migration_dependencies: {}
