It doesn't appear that there is a good way to handle the following scenario in a module:
It turns out that various methods throughout the entity system will reload the ContentEntityType and base field definitions from the class on disk, ignoring the definition passed in to installEntityType(). Since the on-disk definition includes the new field, and that field's module isn't enabled yet, the field definition throws an exception as the associated field type plugin can't be loaded.
The only workaround I've seen without core changes is to remove your old update hooks, and to do them all together in a new update hook. But, it's pretty confusing, especially for new developers who are just trying to add a field. From an API standpoint, it would be much better if any of the code used by \Drupal\Core\Entity\EntityDefinitionUpdateManagerInterface (particularly SqlContentEntityStorage) never reloaded entity definitions from disk and only relied on the passed-in objects.
Closed: outdated
11.0 🔥
The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
We've done many, many Drupal sites since this was worked on, and obviously it hasn't come up since. I think this may have been a fixed in core since, or that at the time hook_post_update_NAME wasn't nearly as well known (even though it was in 8.0.0): https://www.drupal.org/node/2563673 →
Let's close this. Thanks for checking in!
