EntityDefinitionUpdateManager::installFieldableEntityType() calls setProvider($entity_type->getProvider()) on every field storage definition received. That discards the provider EntityFieldManager already assigned to fields added through hook_entity_base_field_info(), and the wrong provider is written to the last-installed field storage definitions.
drush en entity_schema_testdrush en entity_test_updatedrush php:eval "print \Drupal::service('entity.last_installed_schema.repository')->getLastInstalledFieldStorageDefinitions('entity_test_update')['custom_base_field']->getProvider();" prints entity_test_update instead of entity_schema_test.system_post_update_fix_base_field_providers() to repair existing sites by comparing each installed provider against the current one.Review.
Nope.
N/A
Nope.
Nope.
N/A
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
amateescu commentedThis should do it.
Comment #4
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #5
amateescu commentedNot sure what's up with the bot.
Comment #6
catchOne question - does this cause the status report to say that there's an entity definition mis-match, or is provider not taken into account there? Not sure it matters either way - it wouldn't be possible for site owners or module authors to fix anyway, just wondering.
Comment #7
amateescu commentedThe provider is not taken into account there, so nothing changes on the status report page :)