EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids()

Installed file_entity (7.x-2.0-beta1+25-dev) and I saw this error:

vagrant@sitename:/var/www/sites/sitename.dev/www$ drush en file_entity -y
The following extensions will be enabled: file_entity
Do you really want to continue? (y/n): y
WD php: EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7788 of                               [error]
/var/www/sites/sitename.dev/www/includes/common.inc).
Cannot modify header information - headers already sent by (output started at /usr/local/drush-5.9.0/includes/output.inc:37) bootstrap.inc:1233       [warning]
EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7788 of /var/www/sites/sitename.dev/www/includes/common.inc).
Drush command terminated abnormally due to an unrecoverable error.                                                                                    [error]
vagrant@sitename:/var/www/sites/sitename.dev/www$ drush en file_entity -y
file_entity is already enabled.                                                                                                                       [ok]
There were no extensions that could be enabled.

Same here on install via drush.

Probably a silly question, but did you run update.php after updating the module? After I updated the module, I was getting this same error when attempting to upload a file. I realized that I had forgotten to run the update script, and after `drush updb`, the issue seems to have been fixed.

I'm getting this on a fresh profile install with Media and File Entity...

Okay, so, this is odd. I stepped through the entire file upload process and the file being uploaded is saved properly, but it's the retrieval from the database that's failing.

It looks like on the fresh install somehow Drupal does not think that file entities are supposed to have a 'type' column (see the screenshot from IntelliJ's debugger). The file is actually recorded in the database properly (see the other screenshot), but Drupal doesn't actually request the type column from the database, which is why type is missing, causing the exception (since type is the "bundle property" for a file entity).

Curiously, after a cache clear, the fields listing is correct. Somewhere the fields list for the file entity is not being written out correctly.

Attached is what the schema looks like after the cache clear.

update.php also does a cache clear, so that would explain why running it would fix the issue.

Hi GuyPaddock,

Have you made further progress researching this file_entity bug?

I am getting the same error message while importing file entities using features. I think it's the same problem.

I believe this error is caused by a conflict between file_entity and entity_uuid. After installing entity_uuid the schema object for File Entities loses the fields for bundle type and uuid.

@BullMoose: That doesn't seem consistent with my own findings. This error will appear immediately after site install and will reappear if you run update.php, but goes away on a cache clear.

It seems that the way that install.php and update.php populate the entity info cache is somehow not "deep" enough and/or misses hooks that are called during a normal cache clear.

Failing for me right now on install because a pre-exisiting file does not have an $entity->bundle at all. The call stack is deep inside a stack started with bean_block_info(). So it may be related to that. Not sure I am going to go deep into debugging this right now but thought I would share my feedback.

FYI, I do not have the entity_uuid module installed.

Update1: Same issue with alpha1, alpha3 and beta1 too.

It is a problem in the drupal_get_complete_schema function.

It seems that drupal_alter('schema', $schema); does not report correctly the alterations (the type column and the uuid column if uuid is used).

As a workaround I think we could mask it by an entity_info_alter with the relevant infos.

function yourmodule_entity_info_alter(&$entity_info) {
  $entity_info['file']['base table field types']['uuid'] = 'char';
  $entity_info['file']['base table field types']['type'] = 'varchar';
  $entity_info['file']['schema_fields_sql']['base table'][] = 'uuid';
  $entity_info['file']['schema_fields_sql']['base table'][] = 'type';
}

That's a dirty solution but it seems to work.

I've seen this before when entity_get_info() is called with a cold cache, before a full bootstrap and all the modules have been loaded. In that case anything invoking hook_schema_alter() would not get called.

It seems a more global issue as I had the same problem with other entity types (schema_alter not taken into account). I think we should put this issue in core.

Was anyone able to resolve this issue?

#14 does seem to be working, just have uuid module enabled before clearing caches, or some db hacking will be required

I have a theory that this is related to Entity Cache. I think the bad file entity is being loaded into cache, and when it's read from the cache, the exception is thrown.

Is anyone else using Entity Cache?

Disabling Entity Cache didn't fix the issue, but here's a stack trace:

in entity_extract_ids called at profiles/custom/modules/contrib/token/token.tokens.inc (1409)
in field_tokens called at ? (?)
in call_user_func_array called at includes/module.inc (895)
in module_invoke_all called at includes/token.inc (178)
in token_generate called at profiles/custom/modules/contrib/token/token.tokens.inc (810)
in token_tokens called at ? (?)
in call_user_func_array called at includes/module.inc (895)
in module_invoke_all called at includes/token.inc (178)
in token_generate called at includes/token.inc (87)
in token_replace called at profiles/custom/modules/vendor/media/media.module (1168)
in media_file_displays_alter called at includes/module.inc (1101)
in drupal_alter called at profiles/custom/modules/contrib/file_entity/file_entity.file_api.inc (231)
in file_view_file called at profiles/custom/modules/vendor/media/media.module (1098)
in media_get_thumbnail_preview called at profiles/custom/modules/vendor/media/includes/media.browser.inc (241)
in media_browser_build_media_item called at profiles/custom/modules/vendor/media/media.views.inc (83)
in template_preprocess_media_views_view_media_browser called at includes/theme.inc (1125)
in theme called at profiles/custom/modules/contrib/views/plugins/views_plugin_style.inc (375)
in views_plugin_style::render_grouping_sets called at profiles/custom/modules/contrib/views/plugins/views_plugin_style.inc (327)
in views_plugin_style::render called at profiles/custom/modules/contrib/views/theme/theme.inc (49)
in template_preprocess_views_view called at includes/theme.inc (1125)
in theme called at profiles/custom/modules/contrib/views/plugins/views_plugin_display.inc (2605)
in views_plugin_display::render called at profiles/custom/modules/contrib/views/includes/view.inc (1264)
in view::render called at profiles/custom/modules/contrib/views/plugins/views_plugin_display.inc (2677)
in views_plugin_display::preview called at profiles/custom/modules/contrib/views/includes/view.inc (1368)
in view::preview called at profiles/custom/modules/vendor/media/includes/MediaBrowserView.inc (46)
in MediaBrowserView::view called at profiles/custom/modules/vendor/media/includes/media.browser.inc (65)
in media_browser called at ? (?)
in call_user_func_array called at includes/menu.inc (519)
…ecute_active_handler called at index.php (21)

It looks like the problem is with core, Media, FIle Entity, or Views.

I ran into this problem with commerce discounts. Sharing to give some hints for people faced with this.

I had a database transaction nested on load commerce_order entity, then inside that transaction a commerce_line_item entity controller started a new transaction to save a new line item. It would save a line item, store that on entityCache (including the line_item_id) before the database commit happened. The next thing that tried to load another order entity was still inside the top transaction and tried to load a order entity from the database in which it wasn't there and threw 'Missing bundle property on entity of type commerce_line_item'.

Transaction layers looked like this:

1. drupal_transaction
2. savepoint_1

Where drupal_transaction was shared between the first order load and the save and the next load.

In my case it was due to a locking patch I was testing, but I could see this happening in any situation where you have reads and writes inside of transactions.

Here's a truncated backtrace... It seems really odd that the file object would only have the alt key.

Array
(
    [0] => Array
        (
            [file] => profiles/nbcsports/modules/contrib/token/token.tokens.inc
            [line] => 1409
            [function] => entity_extract_ids
            [args] => Array
                (
                    [0] => file
                    [1] => stdClass Object
                        (
                            [alt] => 
                        )

                )

        )

    [1] => Array
        (
            [function] => field_tokens
            [args] => Array
                (
                    [0] => entity
                    [1] => Array
                        (
                            [field_file_image_title_text] => [file:field_file_image_title_text]
                        )

                    [2] => Array
                        (
                            [entity_type] => file
                            [entity] => stdClass Object
                                (
                                    [alt] => 
                                )

                            [token_type] => file
                        )

                    [3] => Array
                        (
                            [clear] => 1
                            [sanitize] => 
                        )

                )

        )

    [2] => Array
        (
            [file] => includes/module.inc
            [line] => 895
            [function] => call_user_func_array
            [args] => Array
                (
                    [0] => field_tokens
                    [1] => Array
                        (
                            [1] => entity
                            [2] => Array
                                (
                                    [field_file_image_title_text] => [file:field_file_image_title_text]
                                )

                            [3] => Array
                                (
                                    [entity_type] => file
                                    [entity] => stdClass Object
                                        (
                                            [alt] => 
                                        )

                                    [token_type] => file
                                )

                            [4] => Array
                                (
                                    [clear] => 1
                                    [sanitize] => 
                                )

                        )

                )

        )

    [3] => Array
        (
            [file] => includes/token.inc
            [line] => 178
            [function] => module_invoke_all
            [args] => Array
                (
                    [0] => tokens
                    [1] => entity
                    [2] => Array
                        (
                            [field_file_image_title_text] => [file:field_file_image_title_text]
                        )

                    [3] => Array
                        (
                            [entity_type] => file
                            [entity] => stdClass Object
                                (
                                    [alt] => 
                                )

                            [token_type] => file
                        )

                    [4] => Array
                        (
                            [clear] => 1
                            [sanitize] => 
                        )

                )

        )

    [4] => Array
        (
            [file] => profiles/nbcsports/modules/contrib/token/token.tokens.inc
            [line] => 810
            [function] => token_generate
            [args] => Array
                (
                    [0] => entity
                    [1] => Array
                        (
                            [field_file_image_title_text] => [file:field_file_image_title_text]
                        )

                    [2] => Array
                        (
                            [entity_type] => file
                            [entity] => stdClass Object
                                (
                                    [alt] => 
                                )

                            [token_type] => file
                        )

                    [3] => Array
                        (
                            [clear] => 1
                            [sanitize] => 
                        )

                )

        )

    [5] => Array
        (
            [function] => token_tokens
            [args] => Array
                (
                    [0] => file
                    [1] => Array
                        (
                            [field_file_image_title_text] => [file:field_file_image_title_text]
                        )

                    [2] => Array
                        (
                            [file] => stdClass Object
                                (
                                    [alt] => 
                                )

                        )

                    [3] => Array
                        (
                            [clear] => 1
                            [sanitize] => 
                        )

                )

        )

)

We aren't using Entity Cache either, but saw this here too. It really does seem like Drupal is caching the entity info before the modules are loaded. It only seems to happen when the cache is rebuilt from update.php or any script that's not fully bootstrapped.

I found the problem!

In template_preprocess_media_views_view_media_browser() you have this:

$files = file_load_multiple($fids);

// Render the preview for each file.
$params = media_get_browser_params();
$view_mode = isset($params['view_mode']) ? $params['view_mode'] : 'preview';

foreach ($vars['rows'] as $index => $row) {
  $file = $files[$row->fid];
  // Add url/preview to the file object.
  media_browser_build_media_item($file, $view_mode);
  $vars['rows'][$index] = $file;
  $vars['rows'][$index]->preview = $file->preview;
}

but since the view result and the rendered output are cached separately, if the rendered output is cleared before the view output is cleared then their are fid's in the view result that no longer exist in the database. file_load_multiple() only returns files that are actually in the database (and doesn't do anything if you pass an invalid id in), and since there is no check to make sure the index actually exists, the second part of the code passes NULL into media_browser_build_media_item(), which then throws an exception later down the line.

I hope this is a good lesson to everyone of why you don't execute database queries at the template/theme level. :)

I realize that this isn't exactly the problem the OP had. Not sure if this issue should be moved to Media or a new one should be created over there.

Since my issue isn't exactly what the OP posted, I've opened #2659876: EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() to cover the issue I'm having.

Yeah, @davidwbarratt, definitely does not seem to be what we've been talking about in this thread. The issue we're running into looks like something that's affecting Core's ability to properly cache entity information during partially-bootstrapped requests.

Same error for me.

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7880 of /var/www/html/d3/includes/common.inc).

my content page says error:
/admin/content
when i hit this page I get the Missing bundle error

I tried this commons patch without success
https://www.drupal.org/files/issues/empty_string_bundle.patch

This is a d6 to d7 upgraded site with 5000 nodes, im using
File Entity 7.x-2.0-beta2
Media 7.x-2.0-beta1
I do not have the entity_uuid or Entity Cache module installed.
Chaos tools 7.x-1.9

I had two missing columns from file_managed at one time, type and uuid. I created them.
Im comparing my site to a fresh clean d7 site that doesn't have the error and I think this could be bad content?

This issue has been around for 5 years!
https://www.drupal.org/node/1266620

I tried the media patch from here, but still have the error
https://www.drupal.org/node/2659876/revisions/9334224/view

Im using Centos7
php4.5
maraidb

I tried to use
Media 7.x-2.0-alpha3
File entity 7.x-2.0-beta1

Same problem. as soon as i disable file entity the content page works and the bundle error goes away

This annoying bug pops up everywhere.

The DrupalDefaultEntityController calls field_attach_load as part of it's own attachLoad method

It seems that field_attach_load (line 688) calls entity_extract_ids() but HOOK_field_attach_load does not fire until line 718.

Here's a potential workaround:

The default entity controller tags it's select query with {entity_type}._LOAD_MULTIPLE

Thus we can implement file_entity_query_file_load_multiple_alter($query){
}
and explicitly add in the 'type' field so that the correct field is pulled from the database regardless of execution order.

forgot to change issue to "needs Review" - re patch #31

hmm.. not sure why the automated test said the patch was invalid - could someone take a look to see if there is an obvious error? I haven't used the automated test system much so I don't know if there's a basic formatting problem here. The code works on my live site though

I sadly have to confirm this bug on every second D7 project atm. It causes SWOD on cron job via page link and interrupts cron via Drush with:

 drush cron
 WD cron: EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() [error]
 (line 7880 of /var/www/yourprojectname/includes/common.inc).

Another question: Since I saw a similar Error in the issue queue of core, but regarding nodes instead of files and by reading thru it, I would like to ask if you all encounter this error on long living projects or also on new setup projects, since the node issue certainly is connected to any orphaned entities.

I fixed similar issue with file_entity 7.x-2.0-beta2 with my patch. It seems that there can be multiple reasons why this error occurs but in my case I believe a deleted file was still referenced somewhere.

My patch #36 is flawed. Don't use it.

I've been running into this error recently, and turns out it's since upgrading to 7.x-2.0-beta3.

I specifically encounter it when attaching files to comments, but I'm sure it crops up in other situations. The source of the problem is in the changes to file_entity.field.inc. In particular this line (310):
$file = (object) $item;
The cast is a hack, $item at this point is not a file object at all, it's just an array that includes the file's fid. It should be:
$file = file_load($item['fid']);
This is effectively what's in beta2, although the logic has been substantially re-arranged.

Patch file attached.

Patch #38 applied cleanly and fixed this issue for me.

In my particular case, #38 does not fix the issue. Moreover, it raises a couple of additional warnings:

Warning: Creating default object from empty value in file_entity_field_formatter_view() (line 315 of file_entity/file_entity.field.inc).
Notice: Undefined property: stdClass::$fid in file_build_content() (line 173 of file_entity/file_entity.file_api.inc).

@interduper - exactly what version of file-entity are you using? The patch was made against 7.x-2.0-beta3+3-dev, and the error report on line 315 doesn't quite match up.

In what circumstance do you get the error? My problem was on uploading attachments, is yours a different case?

I can confirm that the patch in #38 fixes the issue where we had the following error:

EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7911 of /var/aegir/platforms/xyz/xyz/dev/includes/common.inc).

Occurred in an update from 7.x-2.0-beta2 to 7.x-2.0-beta3.

I have the same error but I know how it happens. Apparently, when we delete entity files on the system, entities which refer to these files are broken when we display them. If I look the database, I see in the entity references fields the fid is present. But the corresponding file doesn't exist anymore.

If I study my entity with devel, I will see my field has an empty object instead of the entity file.

The patch #38 doesn't works in my case but, I added a condition file_entity_field_formatter_view() in to verify for each item if it's not an empty item. If it's the case, it's probably a reference to a deleted file so I add an error in the watchdog. My patch works if your file field is multivalue and just ignore missing files.

Maybe we should add a patch to clean references on files when we delete them but I don't look where it is managed.

@Calystod - good call, I haven't encountered that use case, but seems to correspond to other reports involving deleted files. This has clearly been a troublesome bit of code.

I will try to have a look at where it might be possible to clean up broken references. When you have been deleting files, is this under admin/content/file, or by some other method?

I ran in to this issue when using the paragraphs module with a image field using the media browser widget. If I tried to hit the collapse button it would cause an ajax error alert with this error. After applying patch from #45 the error went away and I was able to use the paragraph module with media widget field types. Thanks Calystod!

Reverting to file_entity 7.x-2.0-beta2 worked for me

I ran into this while wrangling with apachesolr/apachesolr_user. After adding a custom user photo field to the Display Suite "Search Index" user display, I got this error when trying to run a batch reindex. Applying #45 resolved the issue. Thanks!

After applying patch #45 I looked at the code and the indenting was rather messy. Turns out the patched code uses tabs for indents, contrary to Drupal coding guidelines (but something I've been guilty of myself in the past!).

I've reworked the patch to use spaces in official Drupal style, attached here. No change in functionality, just neater code layout.

BTW, this, and patch #45, both incorporate the separate fix I posted in #38, so only one patch needs to be applied.

I ran into this problem and after hours of debugging came up with the same fix at #38, but the more comprehensive patch from #51 applies and doesn't give any problems either.

My case it came up after nesting an image field inside a custom file type and the entire object wasn't being passed through (just the file ID).

To add to the noise (there are various causes to this symptom) ..
I've been able to replicate the situation described by @Calystod in #45.
Due to years of oddness in a (migrated from D6) site, it's not impossible for our Database integrity to be a little crap - and we have file field references to a ->fid that no longer exists.
Core quietly ignores those issues (yet does not warn or repair)
file_entity crashes hard.

Looking at devel dump of one of these bad nodes:

(Object) stdClass
  field_media_images (Array, 1 element)
    und (Array, 1 element)
      0 (NULL)

.. where the usual assumption is that an empty field would not even have that 0=>NULL there.

I traced that back to file_field_load() that handles a failure inside file_load_multiple (and invalid fid) thus:

      if (empty($item['fid']) || !isset($files[$item['fid']])) {
        $items[$id][$delta] = NULL;
      }

As identified in this issue and patches above - this then explodes when file_entity_field_formatter_view() does a

      foreach ($items as $delta => $item) {
      ..
        $file = (object) $item;
        ...
        $element[$delta] = file_view($file, $settings['file_view_mode'], $langcode);

without noticing that $item was NULL.

For me (my situation was different from the cache or recursion issues above, but had a similar cause) I'm having to inject

      foreach ($items as $delta => $item) {
      ..
        // Protect ourselves from bad data.
        if (!$item || !$item['fid']) {
          $strings = array(
            '%entity_type' => $entity_type,
            '%entity_id' => $entity->nid,
            '%field_name' => $field['field_name'],
          );
          watchdog('file_entity', 'Invalid file reference. Entity %entity_type/%entity_id has a null %field_name', $strings, WATCHDOG_ERROR);
          continue;
        }

        $file = (object) $item;

.. and now I also have to go and find a way to clean up those integrity issues in the old source data...

* Unexpected input = root cause
* Crashing hard on unexpected input = bad behaviour

I can confirm that #38 is solving the issue in my case. Thanks, Rick!

As has been mentioned there are various possible reasons for this error. For me, it is the problem of drupal_get_schema returning un-altered (not affected by hook_schema_alter) data after a full cache clear, which was alluded to in #15. This causes DrupalDefaultEntityController::buildQuery to only query the core managed_file columns, leaving out "type" which is normally added in file_entity_schema_alter(). Here is a snippet that fixes that problem, though I don't know if it makes sense to go into this patch. (Probably not, as this does seem like something that belongs more in core, as mentioned in #16.)

/**
 * Implements hook_flush_caches().
 */
function mymodule_flush_caches() {
  register_shutdown_function('_mymodule_rebuild_caches');
}

/**
 * Shutdown function that runs after cache clears.
 */
function _mymodule_rebuild_caches() {
  // Rebuild the schema cache before the next page load.
  drupal_get_schema(NULL, TRUE);
}

All that aside, I did test out the patch in #51, and although it didn't fix my particular issue, it didn't cause any additional problems.

#51 fixed my issue, I deleted multiple files from the media module that caused the problem.

Thank you

Subscribing. I've seen this issue before, next time it occurs I will try this patch.

#51 fixed our issue as well. Please commit. Without this patch somehow some nodes got messed up, the node view crashed with this error (as described above) and had to go to the admin theme and edit the node reattaching the file before it would be viewable. Patching/committing is the way to go.

Thanks

Patch #51 fixed my issue, please commit

Hello,

I am having the same problem

EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 8097 of /home/customer/www/theorichel.nl/public_html/includes/common.inc).

and since this thread is years old, I do not know what to do. Apply patch 51?

I am on D 7.98
PHP 7.4.33
File Entity 2.37
Media 2.30

Many thanks in advance.

I am applying the patch in #51 which wants me to remove several lines with the word 'recursive' in it but that word is not in the 2.37 v of the file, the word 'repeated' is. Which word should I use? 'Recursive' from the patch or should I replace that 'Recursive' from the patch with 'repeated'.?
Thanks!

@TheoRichel

This issue was raised against 7.x-2.0-beta3, the current version is 7.x-2.37. The fix here is already incorporated in 2.37, so the patch is not relevant. Are you running the latest version?

It sounds to me that another bug may have crept in that's resulting in the same error message. It would be best to open a new issue, and describe how to replicate the problem.

I reposted: https://www.drupal.org/project/file_entity/issues/3401100
Thanks