Unable to update Drupal 8.6 to Drupal 8.7; Field storage definition for 'type' could not be found in file_update_8700()

It looks like views to me.

Hmm, file has no type field in core right ? This might come from the file_entity module maybe ?

Can you post the output of

drush php-eval "var_export(array_keys(\Drupal::service('entity.last_installed_schema.repository')->getLastInstalledFieldStorageDefinitions('file')));"

I suspect your last installed entity definitions might reference the type field which was added at some point by file_entity

Thanks, how about this one

drush php-eval "var_export(array_keys(\Drupal::service('entity.last_installed_schema.repository')->getLastInstalledDefinition('file')->getKeys()));"

We should not see a 'bundle' key

That's it!

Here's the annotation:

entity_keys = {
 *     "id" = "fid",
 *     "label" = "filename",
 *     "langcode" = "langcode",
 *     "uuid" = "uuid",
 *     "owner" = "uid",
 *   }

You'll note - no bundle.

So you'll need to unset that bundle.

Something like so

$repo = \Drupal::service('entity.last_installed_schema.repository');
$entity_type = $repo->getLastInstalledDefinition('file');
$keys = $entity_type->getKeys();
unset($keys['bundle']);
$entity_type->set('entity_keys', $keys);
$repo->setLastInstalledDefinition($entity_type);

Assuming you have a backup, I think so

This was purely a per-site thing, a carry-over from file entity being enabled at some stage would be my guess.

Thanks for your time and for reporting it, hopefully it helps someone else having this record here.

Adding issue credits for those who helped out.

The same issue...
@waverate, @larowlan - Where to put this #14 code? A custom module or a hook?

@waverate Yes, my issue is similar, but somewhere in menu_link_content.post_update with the following error:

 ------------------- ----------------- ------------- --------------------------
  Module              Update ID         Type          Description
 ------------------- ----------------- ------------- --------------------------
  menu_link_content   make_menu_link_   post-update   Update custom menu links
                      content_revisio                 to be revisionable.
                      nable
  system              add_expand_all_   post-update   Initialize
                      items_key_in_sy                 'expand_all_items'
                      stem_menu_block                 values to
                                                      system_menu_block.
  system              clear_menu_cach   post-update   Clear the menu cache.
                      e                               @see
                                                      https:www.drupal.orgproj
                                                      ectdrupalissues3044364
  taxonomy            make_taxonomy_t   post-update   Update taxonomy terms to
                      erm_revisionabl                 be revisionable.
                      e
  taxonomy            remove_hierarch   post-update   Remove the 'hierarchy'
                      y_from_vocabula                 property from
                      ries                            vocabularies.
  views               exposed_filter_   post-update   Update exposed filter
                      blocks_label_di                 blocks label display to
                      splay                           be disabled.
  views               make_placeholde   post-update   Rebuild cache to allow
                      rs_translatable                 placeholder texts to be
                                                      translatable.
 ------------------- ----------------- ------------- --------------------------


 // Do you wish to run the specified pending updates?: yes.

>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Custom menu links have been converted to be revisionable.
>  [notice] Update completed: menu_link_content_post_update_make_menu_link_content_revisionable
>  [notice] Update started: menu_link_content_post_update_make_menu_link_content_revisionable
>  [error]  Exception thrown while performing a schema update. Die Tabelle tmp_d0929amenu_link_content_revision kann nicht nach menu_link_content_revision umbenannt werden: Die Tabelle menu_link_content_revision existiert bereits.
>  [error]  Update failed: menu_link_content_post_update_make_menu_link_content_revisionable
 [error]  Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable
 [error]  Finished performing updates.

$ drush php-eval "var_export(array_keys(\Drupal::service('entity.last_installed_schema.repository')->getLastInstalledDefinition('menu_link_content')->getKeys()));"
array (
  0 => 'id',
  1 => 'label',
  2 => 'langcode',
  3 => 'uuid',
  4 => 'bundle',
  5 => 'revision',
  6 => 'default_langcode',
  7 => 'revision_translation_affected',
  8 => 'published',

Note that the title of #3039586: Cannot rename tmp_2362aemenu_link_content_revision to menu_link_content_revision and reports of it might be a red herring: This will happen any time you already ran the DB update and that one completed successfully but something else broke the process. So it might not be the real bug.

In any case let's keep this issue about specifically file_update_8700() and file new ones if we find different underlying problems.

@waverate @i.vuchkov: Thanks for taking part in this issue. If you'd like to help us make sure the 8.8.0 update is as smooth as possible, please consider signing up for the beta testing program at https://goo.gl/forms/bMBTMRSY3sKEscUJ3

Since the problem came from the file_entity module shouldn't this issue get back to active and be assigned to the file_entity module?

I have the same problem but I have nowhere to execute code in #14 since the site is completely broken. How else can I execute the code ?
Isn't there a way to do that from drush ?

Also encountering this error, I detected and successfully removed bundle, however it did not help. Any other ideas to try?

TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /home/halberdb/public_html/core/modules/views/src/EntityViewsData.php on line 290 in Drupal\views\EntityViewsData->mapFieldDefinition() (line 387 of core/modules/views/src/EntityViewsData.php).

I have the same issue as one described in #29. I am trying to upgrade core from 8.6.16. to 8.7.2.
Does someone have a solution?

Hi Waverate,

#9:
array (
0 => 'fid',
1 => 'uuid',
2 => 'langcode',
3 => 'uid',
4 => 'filename',
5 => 'uri',
6 => 'filemime',
7 => 'filesize',
8 => 'status',
9 => 'created',
10 => 'changed',
)

#12:
array (
0 => 'id',
1 => 'label',
2 => 'langcode',
3 => 'uuid',
4 => 'revision',
5 => 'bundle',
6 => 'default_langcode',
)

Previously I had removed bundle per your instruction but still encountered the same error. Any thoughts on a new strategy?

@waverate,

Not migrated from D7, but it was an early 8.0.x release with composer added post-installation.

I don't think so. The site previously had Commerce 2.x installed but later removed, but I don't recall Commerce using File Entity as a dependency.

Hi @Waverate @dougiep.

The same situation for me. Previously I had removed bundle per instructions from #9 and #12, but still, the same error occurs.
How I know it's a D8 project from the beginning. And File Entity Module isn't installed.

Any thoughts regarding this?

I'm having this same issue. How is this possibly 'Closed (fixed)'. I don't get it.

I still have an error when trying to install the project from configs http://prntscr.com/o5wqyl

TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /var/www/fsc/fsc.org/web/core/modules/views/src/EntityViewsData.php on line 290 in Drupal\views\EntityViewsData->mapFieldDefinition() (line 387 of /var/www/fsc/fsc.org/web/core/modules/views/src/EntityViewsData.php).

My configuration worked fine until I install module Deploy. But we need this module and need to fix this error. Does someone have an idea of what we can do with this error?

I'm experiencing the same problem.

1. Was this a site migrated from D7? -> Some data was migrated via a CSV file.

2. Is/was the File Entity Module installed on the D8 site? D7 site? -> Error becomes apparent when file_entity module is uninstalled.

@lukus
1. No, it's a new project on D8
2. We haven't module File Entity on our project. I found only module Entity, but I think it's not a problem

Hey @shefarik

Running the code snippet in #14 in a hook update seems to solve the problem for me.

e.g.

function your_module_update_8001() {
  $repo = \Drupal::service('entity.last_installed_schema.repository');
  $entity_type = $repo->getLastInstalledDefinition('file');
  $keys = $entity_type->getKeys();
  unset($keys['bundle']);
  $entity_type->set('entity_keys', $keys);
  $repo->setLastInstalledDefinition($entity_type);
}

and then run `drush updatedb`

Make sure you backup prior to running.

Hi @Waverate and others,

I still have issues with this kind of error. I try to update from 8.6.16 -> 8.7.5. It is originally a Drupal 8 site and 8.x-2.0-beta4 is installed since before.

As per #9:

drush php-eval "var_export(array_keys(\Drupal::service('entity.last_installed_schema.repository')->getLastInstalledFieldStorageDefinitions('file')));"
array (
  0 => 'fid',
  1 => 'uuid',
  2 => 'langcode',
  3 => 'uid',
  4 => 'filename',
  5 => 'uri',
  6 => 'filemime',
  7 => 'filesize',
  8 => 'status',
  9 => 'created',
  10 => 'changed',
  11 => 'field_image_title_text',
  12 => 'field_image_alt_text',
  13 => 'type',
  14 => 'path',
)

As per #12:

drush php-eval "var_export(array_keys(\Drupal::service('entity.last_installed_schema.repository')->getLastInstalledDefinition('file')->getKey()));"
array (
  0 => 'id',
  1 => 'label',
  2 => 'langcode',
  3 => 'uuid',
  4 => 'revision',
  5 => 'bundle',
  6 => 'default_langcode',
)

I run "composer update symfony/http-foundation egulias/email-validator drupal/core --with-dependencies" without problems.

I unset "bundle" as per #14.

I run "drush updb" and it gives the error:
TypeError: Argument 3 passed to DrupalviewsEntityViewsData::mapFieldDefinition() must implement interface DrupalCoreFieldFieldDefinitionInterface, null given, called in /home/xxx/core/modules/views/src/EntityViewsData.php on line 290 in DrupalviewsEntityViewsData->mapFieldDefinition() (line 387 of /home/xxx/core/modules/views/src/EntityViewsData.php).

If i try to open the site in the browser, it is not possible. Instead I get the same error, but it also adds several other lines. The first one is:
"DrupalviewsEntityViewsData->mapFieldDefinition('profile', 'langcode', NULL, Object, Array) (Line: 290)"

It doesn't help to update to file_entity 8.x-2.0-beta7.

Any suggestions?

(Everything seems to work fine if I just run "composer update" and then "drush updb". But I don't think just running "composer update" is recommended.)

@bengt please see Comment #6 at : https://www.drupal.org/project/drupal/issues/3058082#comment-13174026

It resolved the issue for me.

@dougiep Thanks that did the trick!

So to be able to update (without using the command "composer update") from 8.6.16 to 8.7.6 I did the following:

1. Changed in core/composer.json: "egulias/email-validator": "^1.2" --> "egulias/email-validator": "^2.0"

2. Deleted the following from [root]/composer.json (see https://www.drupal.org/project/drupal/issues/3020337):
"merge-plugin": {
"include": [
"core/composer.json"
],
"recurse": false,
"replace": false,
"merge-extra": false
},

3. Run: composer update symfony/http-foundation egulias/email-validator drupal/core --with-dependencies

4. Patched /core/modules/views/src/EntityViewsData.php as suggested by @dougiep in #44.

5. Run: drush updb
No errors!

6. Run: drush cr
No errors!

Site seems to work fine! Only one notice:" Notice: Undefined index: langcode i Drupal\views\EntityViewsData->getViewsData() (row 292..." Is this notice somehow connected to the issue and the patch?

@dougiep or any one else: I have a few questions:

1. I did not unset "bundle" as per #14. Should I do that?

2. Will I need to patch EntityViewsData.php every time I do an update (if not a "real" solution has been committed by then)? Does this patch have any disadvantages? Is this patch needed because of a bug in Drupal core or because of a bug in a contributed module?

3. Should I run "composer require 'drupal/file_entity:^2.0'" as suggested in #21? Earlier betas do not seem to be compatible with Drupal 8.7.x.

4. Do you agree that one should not use the brute command "composer update" (which also did solve this issue)? Or can it be legitimate sometimes?

1. unset bundle: Yes, you should do that.
2. patch EntityViewsData.php every time: Yes, unfortunately core committer qualifies it as a workaround. I disagree, despite the fact it is not a complete solution, if does fix bad code!
3.require file_entity: No idea whether that is a requirement.
4. composer update: advice against using it without whitelisting requirements. Consider current use of version constraints poor, so I won't rely on it. Default behavior is too optimistic for my liking. Obviously, you can use --dry-run to find out what it wants to do, run again without --dry-run when you agree. So, it is legitimate, just not what I want.

Thanks @mmjvb!

If I understand you correctly, I should leave the patched EntityViewsData.php there after running "drush updb", and not put back the unpatched version. Correct?

Yes, indeed. Keep those fixes. They are not solving the actual problem. They probably should log errors besides only running code in valid situations. Maybe even throw errors.

Also suggest to solve your issue properly. You converted drupal/drupal step by step instead of rebuilding your codebase starting with a proper distribution. With every issue you run into, you'll wonder whether that is caused by the bad start!

Thanks @mmjvb!

I have seen these kind of comments about "drupal/drupal" and "proper distribution" before. In this case it is a bought template (with a full installation as a starting point) and in [root]/composer.json it says at the top '"name": "drupal/drupal"'. I have to confess that I haven't entered deeply into this "issue". Would you say that this commercial template have done it wrong? Is it posssible to "rebuild" this codebase now (it is a live website)? Can you direct me to a page which explains this "issue" and gives instructions how to "rebuild" codebase without crashing the site?

Based on the information provided it is hard to say they have done it wrong. D.O. still points you to download drupal/drupal. It is still used for developers to contribute to drupal. Not sure I understand what you mean by bought template. Would expect to be able to use that template in any environment, including drupal/drupal. The mistake you made is to use it to become your site. For site building use a proper distribution. One that allows you to use composer to update things in your codebase, including drupal/core.

You can always rebuild your codebase, even for a live site. Suggest to dry-run it on a copy of the live site. There is always the danger of things going wrong. Every site is unique! As of D8, composer is used to create the distribution. That still allows you to maintain your site the traditional way. There are even sites that don't use composer at all. With composer the rebuild becomes very easy, composer is only concerned with the codebase. It doesn't touch the database, yet. Normally speaking your site doesn't depend on the organization of the codebase. However, there are situations where it does.

Not aware of documentation on rebuilding codebase. It does resemble activity involved in moving a site. Instead of using existing codebase, build a new one and point to the database.

Thanks @mmjvb!

I'm running into this error right after disabling the multiversion module. Do not know if it's related