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