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
jofitzAs 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
jofitzThe user langcode field should not be empty because it is required to display user fields (which have a langcode by default).
Comment #5
jofitzCombine the initial fix with the change to the test.
Comment #6
quietone commentedComment #8
jofitzUpdated for v8.1.1.
Comment #9
jofitzVersion changed in error.
Comment #10
vasi 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
jofitzThe 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
jofitzAdd test for d7 user *with* a langcode, as suggested by @vasi.
(the status will be returned to "postponed" once this test passes)
Comment #15
jofitzUpdate patch for d8.1.x-dev.
Comment #17
jofitzInclude in the patch the previously (accidentally) omitted MigrateProcessPlugin.
Comment #18
jofitzSetting back to postponed dependent on #2752281: Add DefaultConfigValue MigrateProcessPlugin.
Comment #19
quietone 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
jofitzRe-rolled patch.
Comment #21
jofitzApply 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
jofitzSetting back to postponed dependent on #2752281: Add DefaultConfigValue MigrateProcessPlugin.
Comment #23
quietone commented@Jo Fitzgerald, of course you can.
Comment #25
damienmckennaRerolled.
Comment #27
jofitz@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.