Problem/Motivation
The d7_user.yml migration template migrates the language field even if it is empty, i.e.:
...
process:
...
langcode: language
preferred_langcode: language
preferred_admin_langcode: language
...
As a result custom user fields (which do have a language) are not displayed correctly.
Proposed resolution
On my site the default langcode is en so I have used a hook_migration_create()
to make the required change:
if ($migration->id() == 'd7_user') {
$process = $migration->getProcess();
$process['langcode'] = array(
'plugin' => 'default_value',
'source' => 'language',
'default_value' => 'en',
);
$process['preferred_langcode'] = array(
'plugin' => 'default_value',
'source' => 'language',
'default_value' => 'en',
);
$process['preferred_admin_langcode'] = array(
'plugin' => 'default_value',
'source' => 'language',
'default_value' => 'en',
);
$migration->setProcess($process);
}
This is equivalent to make the following changes to the d7_user.yml
migration template:
...
process:
...
langcode:
plugin: default_value
source: language
default_value: en
preferred_langcode:
plugin: default_value
source: language
default_value: en
preferred_admin_langcode:
plugin: default_value
source: language
default_value: en
...
I suggest a general version of this is required, using the default_langcode of the site as the default value for these three fields. I suspect this will require a custom MigrateProcessPlugin (unless it is possible to pass system.site.default_langcode into the default_value MigrateProcessPlugin).
Remaining tasks
Decide how to solve this
Solve it!
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#25 | drupal-n2671312-25.patch | 3.71 KB | DamienMcKenna |
#21 | core-migrate_d7_users_without_language-2671312-21.patch | 4.99 KB | jofitz |
#21 | interdiff.txt | 1.53 KB | jofitz |
Comments
Comment #2
jofitz CreditAttribution: jofitz commentedAs proposed, I have written a custom MigrateProcessPlugin that fills missing fields with a value from configuration (in this case system.site / default_langcode). Here is the patch.
Comment #4
jofitz CreditAttribution: jofitz commentedThe user langcode field should not be empty because it is required to display user fields (which have a langcode by default).
Comment #5
jofitz CreditAttribution: jofitz commentedCombine the initial fix with the change to the test.
Comment #6
quietone CreditAttribution: quietone as a volunteer commentedComment #8
jofitz CreditAttribution: jofitz commentedUpdated for v8.1.1.
Comment #9
jofitz CreditAttribution: jofitz commentedVersion changed in error.
Comment #10
vasi CreditAttribution: vasi at Evolving Web commentedI like this approach! It would be great for #2751223: D6 & D7 users are migrated into D8 with incorrect langcode too. Should we test that users can have a langcode in the D7 user table, too?
Comment #11
mikeryanI like it too! But, a new generally-useful process plugin like this should have its own tests (including a test of the 'strict' option, which is not tested here in the user scenario). Ideally, actually, adding a new general-purpose plugin should be a separate issue, and the user langcode bug dependent on it, although both the plugin and the application are simple enough I wouldn't insist on it...
Comment #12
jofitz CreditAttribution: jofitz at ComputerMinds commentedThe new migration process plugin has been set up in a separate ticket: #2752281: Add DefaultConfigValue MigrateProcessPlugin. This ticket is now dependent on that and so is postponed for the time-being.
Comment #13
jofitz CreditAttribution: jofitz at ComputerMinds commentedAdd test for d7 user *with* a langcode, as suggested by @vasi.
(the status will be returned to "postponed" once this test passes)
Comment #15
jofitz CreditAttribution: jofitz at ComputerMinds commentedUpdate patch for d8.1.x-dev.
Comment #17
jofitz CreditAttribution: jofitz at ComputerMinds commentedInclude in the patch the previously (accidentally) omitted MigrateProcessPlugin.
Comment #18
jofitz CreditAttribution: jofitz at ComputerMinds commentedSetting back to postponed dependent on #2752281: Add DefaultConfigValue MigrateProcessPlugin.
Comment #19
quietone CreditAttribution: quietone as a volunteer commentedThis is really nice.
What about the language for D6 user migrations? Should that be looked at here or in another issue?
Two changes for the fixture.
Please change, this is the same email address as uid 1.
Should be a language installed on the fixture. Currently, English and Icelandic are installed, so please change to 'is'.
Comment #20
jofitz CreditAttribution: jofitz at ComputerMinds commentedRe-rolled patch.
Comment #21
jofitz CreditAttribution: jofitz at ComputerMinds commentedApply changes requested by @quietone.
@quietone, can I be cheeky and ask you to review #2752281: Add DefaultConfigValue MigrateProcessPlugin, please, which is currently holding up this ticket. Thanks.
Status set to "Needs review" to test the patch, but will be returned to "Postponed" once the patch is confirmed.
Comment #22
jofitz CreditAttribution: jofitz at ComputerMinds commentedSetting back to postponed dependent on #2752281: Add DefaultConfigValue MigrateProcessPlugin.
Comment #23
quietone CreditAttribution: quietone as a volunteer commented@Jo Fitzgerald, of course you can.
Comment #25
DamienMcKennaRerolled.
Comment #27
jofitz CreditAttribution: jofitz at ComputerMinds commented@DamienMcKenna imo there's not much point in re-rolling this patch until #2752281: Add DefaultConfigValue MigrateProcessPlugin is RTBC.
Comment #28
Gábor Hojtsy#2751223: D6 & D7 users are migrated into D8 with incorrect langcode worked on the same problem in Drupal 6 and now in Drupal 7 and devised a slightly different solution where it provides different fallback values based on the invalidity of the source language, dealing with not only the empty case (where instead of the site default language, English should be the fallback), but also the invalid language case, where indeed, the site default language should be the fallback. I think that solution is a lot more complete and while it does not provide or depend on a general fallback solution, its logic is so specific to user languages, that that makes sense.
It would be nice to take the credits of the issue here and move it over there to be fair with all contributors on this issue, which would require at least the patch posters to comment there too.