Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mismatched field definitions in status report #500

Open
donquixote opened this issue Jan 3, 2022 · 2 comments
Open

Mismatched field definitions in status report #500

donquixote opened this issue Jan 3, 2022 · 2 comments

Comments

@donquixote
Copy link
Contributor

donquixote commented Jan 3, 2022

(I think I can find a solution myself, but having it here can be useful for others who have the same problem.)

Problem

We have the following error in the status report: 

ENTITY/FIELD DEFINITIONS
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.

Content

  • The Alternative title field needs to be installed.
  • The Navigation title field needs to be installed.
  • The Content owner field needs to be installed.
  • The Redirect link field needs to be installed.

After upgrading to Drupal 9, we get this additional warning:

  • The node.oe_timeline field needs to be updated.
     

Investigation

With some investigation, I found that:

  • oe_content module declares some base fields in oe_content_entity_base_field_info().
  • I assume if oe_content was first installed with a version that did not have these base fields, the fields will never be installed, and the warning will show up in the status report.
  • We do have base fields overrides related to these fields, e.g. config/sync/core.base_field_override.node.data.oe_content_navigation_title.yml. Not sure how these affect the situation.
  • I don't know yet what's up with node.oe_timeline.

Solution

I found this change record in drupal.org with instructions:
https://www.drupal.org/node/3034742 "Support for automatic entity updates has been removed"

We can add a hook_update_N() in a custom module to install these fields.

However, I wonder, shouldn't this be done by oe_content module?
Putting this in a custom module can be good enough in practice, but is conceptually wrong, because the custom module does not own these fields. It can lead to unreliable results if we install and uninstall the custom module (depends if we put it in an install hook or an update hook).

@donquixote
Copy link
Contributor Author

This code seems to work, the 4 errors are gone:

function MODULENAME_install() {
  $etm = \Drupal::entityTypeManager();
  $entity_type = $etm->getDefinition('node');
  $edum = \Drupal::entityDefinitionUpdateManager();
  /** @var BaseFieldDefinition[] $fields */
  $fields = oe_content_entity_base_field_info($entity_type);
  foreach ($fields as $field_name => $field_storage_definition) {
    $edum->installFieldStorageDefinition(
      $field_name,
      'node',
      'oe_content',
      $field_storage_definition);
  }
}

This is a hook_install(), because the custom module is new.
It would probably be good to have a mechanism to prevent the code from running more than once, in case we uninstall + reinstall the module.

Observed database changes after running this operation:

  • new table columns added in node_field_data for oe_content_short_title, oe_content_navigation_title, oe_content_legacy_link__(uri,title,options), but not for oe_content_content_owner.
  • Database tables node__oe_content_content_owner and node_revision__oe_content_content_owner already existed before running this hook. The other fields don't have their dedicated tables.

I don't know yet what to do about oe_timeline.

@donquixote
Copy link
Contributor Author

@brummbar This could be something wrong with the specific project I am working on.
The first version of oe_content on that project seems to be 1.10.0, according to the project's git history. In 1.10.0, the oe_content_entity_base_field_info() was already present.
So the idea that this was caused by an old version of oe_content might not be true.

For now we are going to fix this with a custom module update hook within the project.
We can wait until others report the same problem. Hopefully they will find this issue somehow. Perhaps a sibling issue in OES will help with this?

The other one, for oe_timeline, should be fixed in oe_content. For now we are going to use the PR as a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant