Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We've attempted to upgrade core from 8.6.15 to 8.7.1 (security update) but the file_entity module indicates the following error:
"Mismatched entity and/or field definitions"
"The File type field needs to be updated"
Our problem seems similar to issue 3033883 although that issue involves uninstalling the file_entity module and we are just trying to upgrade core.
Also, starting with 8.7 there is no support for automatic entity updates so we're at a loss as how to resolve this. Any help or suggestions would be appreciated.
Comment | File | Size | Author |
---|---|---|---|
#9 | file_entity-8.7-update-3056070-9.patch | 790 bytes | Berdir |
Comments
Comment #2
joseph.olstad#2998810-5: Do we need to migrate to Drupal core media?
https://www.drupal.org/project/migrate_file_to_media
Comment #3
joseph.olstadworkaround here:
#2914935-73: Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.4
Comment #4
dgilbert CreditAttribution: dgilbert at SEI Global Services Inc. commentedThanks for the info. Just to confirm, our options are to switch over to the core media entity or write a custom module and use hook_update_N to update/fix the schema? Or a third option would be to (temporarily) install the devel_entity_updates module on our prod environment.
Comment #5
Olarin CreditAttribution: Olarin at Kosada commentedSo on a technical level, if I'm understanding correctly, the issue is that after the D8.7 update, the type column in the file_managed table does not have NOT_NULL turned on, but the storage schema "file.field_schema_data.type" in the key_value table says it should. The workaround in https://www.drupal.org/project/file_entity/issues/2914935#comment-13110657 changes the configuration in the key_value table to reflect the current reality of the database table. I'm curious, though - is the more "correct" workaround to change the configuration described in key_value, or to change the database column settings? I'm hesitant to use the workaround without knowing anything about why the database settings apparently changed and what the "correct" / expected situation is.
Comment #6
jldust CreditAttribution: jldust commentedHas their been any update on this issue? I saw a possible patch being worked on, but want to make the right call as to what is the best course of action.
Comment #7
joseph.olstadthere is a workaround here:
#2914935-73: Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.4
Comment #8
joseph.olstaduntil someone proposes a patch for file_entity with a better idea , the workaround hook_update is probably the way to go if you have your own custom module add that
as mentioned in #2914935-73: Mismatched entity and/or field definitions for File 'type' field after updating to Drupal 8.4
Comment #9
BerdirThat fix is backwards, it has to be not null, the problem is that we incorrectly expect the opposite, because the *current* schema is based on the last installed entity type definition apparently :)
This is the proper fix for that, unfortunately that means that sites who did such a custom update like that one above will need to redo and correct their last-installed definition back to the correct value.
Comment #11
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThe patch looks good, just a minor nit:
"flag" -> "file" :)
Or better yet, I think it would make more sense like this:
Fix the last installed definition for the 'file' entity type.
Comment #12
BerdirThose test fails are unrelated, created #3067048: Convert FileEntityCacheTagsTest to phpunit for that.
Comment #14
Berdir@amateescu: Oops, crosspost. Fixed.
Comment #16
joseph.olstadThanks @Berdir
Comment #18
edysmpI did an update from 8.7.12 to 8.8.5 and i am still seeing the message on status report page.
8004 and 8005 updates ran without problems.
What could be causing this issue?
EDIT:
Current message: https://paste.pics/b5a46e32dcd21841a0bc46dc49744078
Comment #19
edysmpCould devel_entity_updates module taken in account in this case? It resolve the issue.
Comment #20
websiteworkspace CreditAttribution: websiteworkspace commented... and this odd Drupal nightmare continues ...
When people, including myself, see bugs like this go for years without being properly addressed and properly fixed, we wonder whether we should laugh, cry, or be angry, that these sorts of circumstances occur with a software system such as Drupal.
This sort of circumstance, with this sort of problem, is all the more ironic for a software platform that is touted by its leaders as being by professionals for professionals.
The bug/problem still is NOT actually fixed!
Comment #21
joseph.olstadPlease re-read the file_entity project page
Comment #22
loopy1492 CreditAttribution: loopy1492 commentedI came to this thread from a different specific issue, but the result is the same. Developers without the option of going in and messing with the database need to risk https://www.drupal.org/project/entity_update . I can 't think of any other way to do this.
Comment #23
kaipipek CreditAttribution: kaipipek commentedHow is this bug fixed? We are in the latest Drupal 9.3.2 and we still receive this error message. We have spent numerous hours reading through bug reports and comments related to this issue prior and after Drupal 8.4 version, but none of the workarounds work for us. For instance changing the "not null" setting of the file_managed table type field does not change anything and key_value table does not have a row with name field value "file.field_schema_data.type" that we could tweak.