This seems like a critical bug to me, if it's not just a user error issue on my end.

But, recently, I was working on a D7 -> D8 migration task of migrating users, and while the field data was migrating properly into the D8 field data tables, the fields in the UI were not loading with any data.

I was about to lose my mind figuring out why it wasn't working, then I installed a Drupal 8.3.7 vanilla site, added a plain text field to the user entity, created a new user, added dummy data into that field, saved. Sure enough, the value from the field made it into the field_data_field_test table in the DB, but after save, the value is no longer present in the field in the UI - same thing.

Comments

joshua.boltz created an issue. See original summary.

joshua.boltz’s picture

Priority: Normal » Critical
damienmckenna’s picture

Priority: Critical » Major

You're saying that the data is stored in the table when the user is first created but doesn't show when the user account is edited again. What happens if you save the record after you load up the edit form - is the previous data erased or does it quietly remain in the table?

joshua.boltz’s picture

Yeah, if i then save the user again after it's been created, then the fields populate.

Steps to reproduce:
* Create new user
* Add a value for a field
* Check the user__FIELD_NAME table to see if the value is stored in the FIELD_NAME_value column, which it does in my case
* Edit the user that was created
* Save, and notice the fields are not populated in the UI
* Now, it seems to be working, and may be an issue with how migrations create the users...
If i create the user via the UI, add a field, save to create...when i edit the user, the fields are populated.
But, if i created users via migration, edit one, the fields are blank, and if i edit one and Save, then the fields are populated.

swentel’s picture

@joshua.boltz The problem might be language during the migration. Check the langcode of the user in the users_field_data table and in the dedicated field table. If they don't match, then that is (normally) the problem. If you'd manually change the langcode in the dedicated table to the langcode matching the user, it should show up (after maybe a cache clear as entities are cached of course)

cruno’s picture

The problem was the 'langocde' map in the config. The Drupal 7 langcode did not match the Drupal 8 langcode format.

When I set a default value for langcode in the migration config the fields showed as normal.

langcode:
        plugin: default_value
        default_value: en
cilefen’s picture

cilefen’s picture

Oh wait, that issue is old. Hmm..was that migration before 8.3.0?

tim bozeman’s picture

Wow, that one was beating me. Thank you @cruno!!

Version: 8.3.7 » 8.3.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

Version: 8.3.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Status: Active » Closed (works as designed)
Issue tags: +Bug Smash Initiative

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging Drupal core issues with the priority 'Major'.

Based on #4 saying it was migration specific, and the suggested fix in #6, and then confirmation in #9 that this fixes it, I'm going to mark this 'works as designed'.

If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".