www.aleph1.co.uk Git - yaffs-website/blob - web/modules/contrib/migrate_plus/migrate_example/config/install/migrate_plus.migration.beer_user.yml

   1 # Migration configuration for user accounts. We've described most of what goes
   2 # into migration configuration in migrate_plus.migration.beer_term.yml, so won't
   3 # repeat that here.
   4 id: beer_user
   5 label: Beer Drinkers of the world
   6 migration_group: beer
   7 source:
   8   plugin: beer_user
   9 destination:
  10   plugin: entity:user
  11 process:
  12   pass: password
  13   mail: email
  14   init: email
  15   status: status
  16   roles:
  17     plugin: default_value
  18     default_value: 2
  19
  20   # Here's a new process plugin - dedupe_entity. Our source site allowed there
  21   # to be multiple user accounts with the same username, but Drupal wants
  22   # usernames to be unique. This plugin allows us to automatically generate
  23   # unique usernames when we detect collisions.
  24   name:
  25     plugin: dedupe_entity
  26     # The name of the source field containing the username.
  27     source: username
  28     # These next two settings identify the destination-side field to check for
  29     # duplicates. They say "see if the incoming 'name' matches any existing
  30     # 'name' field in any 'user' entity".
  31     entity_type: user
  32     field: name
  33     # Finally, this specifies a string to use between the original value and the
  34     # sequence number appended to make the value unique. Thus, the first 'alice'
  35     # account gets the name 'alice' in Drupal, and the second one gets the name
  36     # 'alice_1'.
  37     postfix: _
  38
  39   # Another new process plugin - callback. This allows us to filter an incoming
  40   # source value through an arbitrary PHP function. The function called must
  41   # have one required argument.
  42   created:
  43     plugin: callback
  44     # The 'registered' timestamp in the source data is a string of the form
  45     # 'yyyy-mm-dd hh:mm:ss', but Drupal wants a UNIX timestamp for 'created'.
  46     source: registered
  47     callable: strtotime
  48
  49   # Our source data only has a single timestamp value, 'registered', which we
  50   # want to use for all four of Drupal's user timestamp fields. We could
  51   # duplicate the callback plugin we used for 'created' above - but we have a
  52   # shortcut. Putting an @ sign at the beginning of the source value indicates
  53   # that it is to be interpreted as a *destination* field name instead of a
  54   # *source* field name. Thus, if a value we need in more than one place
  55   # requires some processing beyond simply copying it directly, we can perform
  56   # that processing a single time and use the result in multiple places.
  57   changed: '@created'
  58   access: '@created'
  59   login: '@created'
  60
  61   # Yet another new process plugin - static_map. We're making a transformation
  62   # in how we represent gender data - formerly it was integer values 0 for male
  63   # and 1 for female, but in our modern Drupal site we will be making this a
  64   # free-form text field, so we want to replace the obscure integers with
  65   # simple strings.
  66   field_migrate_example_gender:
  67     plugin: static_map
  68     # Specify the source field we're reading (containing 0's and 1's).
  69     source: sex
  70     # Tell it to transform 0 to 'Male', and 1 to 'Female'.
  71     map:
  72       0: Male
  73       1: Female
  74     # If the input is missing, leave the field empty. Without this, an empty
  75     # or invalid source value would cause the user record to be skipped
  76     # entirely.
  77     bypass: true
  78
  79   # This looks like a simple migration process plugin, but there's magic
  80   # happening here. We import nodes after terms and users, because they have
  81   # references to terms and users, so of course the terms and users must be
  82   # migrated first - right? However, the favbeers field is a reference to the
  83   # beer nodes which haven't yet been migrated - we have a circular relationship
  84   # between users and nodes. The way the migration system resolves this
  85   # situation is by creating "stubs". In this case, because no beer nodes have
  86   # been created, each time a beer is looked up against the beer_node migration
  87   # nothing is found, and by default the migration process plugin creates an
  88   # empty stub node as a placeholder so the favbeers reference field has
  89   # something to point to. The stub is recorded in the beer_node map table, so
  90   # when that migration runs it knows that each incoming beer should overwrite
  91   # its stub instead of creating a new node.
  92   field_migrate_example_favbeers:
  93     plugin: migration_lookup
  94     source: beers
  95     migration: beer_node
  96
  97 migration_dependencies: {}
  98
  99 # When a module is creating a custom content type it needs to add an
 100 # enforced dependency to itself, otherwise the content type will persist
 101 # after the module is disabled. See: https://www.drupal.org/node/2629516.
 102 dependencies:
 103   enforced:
 104     module:
 105       - migrate_example