when I enable the module, and then try to see the content list at admin/content I get this error:

EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7539 of /home2/hohumrec/public_html/includes/common.inc).

I'm using current latest dev version (May 9th) but it shows as '7.x-1.1+0-dev' in the module list?

I disable the module, and admin/content is again reachable without a problem.

Any ideas?

Files: 
CommentFileSizeAuthor
#13 file_entity_schema_field_type-1569952-13.patch604 bytesdarrenmothersele
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch file_entity_schema_field_type-1569952-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Status:Active» Postponed (maintainer needs more info)

What version of Media do you use?

Did you update Media/File Entity from earlier versions, including the 1.x branch? If so, dud you run update.php?

Yeah this sounds like you possibly updated from Media 1.x, in which case you always need to delete the old modules files before copying over the new version. As well as run update.php.

I don't think I did, It's on a new dev, and I think I went straight to latest dev but I'll certainly try to clean out and reinstall the module now... will edit post shortly with findings.
Thanks!

----

nope, still happening :( I only started trying using this module recently so must have been v2 from the start.
I think it worked originally but I installed media, mediefield, media:youtube and media:vimeo and at some point it stopped working. Now all those are disabled, but its still happening as soon as I enable field element.

Got this error after updating to D7.14, disabling the module made the problem go away. I was using File Entity v7.x-2 unstable. Guess I'll just wait until the full release is out.

Priority:Critical» Normal

Without knowing what the problem is or where it's coming from specifically from a function/parameter perspective, there's not much we can do to improve or fix. Waiting for a stable release isn't going to do much good.

Hi Dave, if you have any ideas how I might be able to find what might be causing it let me know - but bear in mind I'm just a humble user, not a dev or maintainer, but happy to try and help find the cause.

I'm getting this too. It doesn't only crash at admin/content, it makes forum unreachable too.

I believe there is a problem between the module and forum's (or comments) attachments (they are a file field of comments in my website). But can't say more for now.

D7.14
file entity 7.x-2.0-unstable5+2-dev or even the "unstable stable"
media module 2 not enabled
Entity API 7.x-1.0-rc2

____________________________________
UPDATE:
I found the solution. This happens when the column "type" in the table"file_managed" is empty. (e.g., it can be empty when manually migrating files and db from other cms)

A quick dirty solution is to run sql query setting type column=filemime column.

I don't know if this is the right solution or how "type" column should be filled, but it will let you access your site/forum/content/images/attachments.

Similar link, even if it was for 1.x
http://drupal.org/node/1266620

Thanks for this info robertorc87
(no idea how this happened, or whether creating more content will create more empty types for new files?!)

Much appreciated!

I had the same problem with loading /admin/content after upgrading from 5.x to 6.x directly to 7.x with file entity 7.x-2.0-unstable6+0-dev, embedded media field 7.x-1.0-alpha1, media 7.x-2.0-unstable6+1-dev and Media: YouTube7.x-1.0-beta3. I found the problem went away after disabling the module dependency chain down to file entity.

Solution: I found this sql code from HongPong in a comment here (by way of robertorc87's "similar link" in #7). I just added the image/tiff at the end:

UPDATE file_managed set type = 'application' where filemime = 'application/pdf' OR filemime = 'application/msword' OR filemime = 'application/rtf';
UPDATE file_managed set type = 'audio' where filemime = 'audio/mpeg';
UPDATE file_managed set type = 'image' where filemime = 'image/jpeg' OR filemime = 'image/png' OR filemime = 'image/png' OR filemime= 'image/gif' OR filemime= 'image/tiff';

After running it, just check the type column in the file_managed table for any further blank rows. Then enable the file entity module and the content admin page should load.

Hopefully this will help people who have problems with the content admin page not loading.

Status:Postponed (maintainer needs more info)» Needs work

Fix in #9 worked for me too. Thanks mennonot!

To answer the maintainer's question, I experienced this error with Media 2.x so it wasn't a version incompatibility. And I couldn't disable the module because I have Panopoly running; I'd have to disable half my site first! I can also confirm that this bug exists in unstable6.

I'm wondering if we can write a patch for this. What exactly is the problem? Should the module simply run the mysql query itself, as a sort of housecleaning? Maybe when cron runs?

I was getting the same error when trying to access admin/content with this module enabled. I'm using the latest dev. I've checked the database and the type field is already set, but I still get the error and can't access admin/content.

I clear cache and that solves it.

Then I install bean module and breaks again. I.e. access admin/content and get EntityMalformedException: Missing bundle property on entity of type file.

I'm confused... Why would bean be causing malformed file entities? Why would having bean installed affect admin/content?

I'm still getting this error after totally removing bean, and rebuilding without bean.

I can fix it on one site with just a cache clear, but this site is used (with Deploy module) to push content to a second site. Nothing (not even clearing cache) fixes it on the second site, unless I add this into file_entity_entity_info_alter(&$entity_info)...

  $entity_info['file']['schema_fields_sql']['base table'] += array('type');

I noticed by looking at a backtrace and seeing that it was failing somewhere inside file_save() during a call to entity_load_unchanged().

StatusFileSize
new604 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch file_entity_schema_field_type-1569952-13.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Patch attached, I wouldn't go as far to say this fixes anything, but it does seem to help matters.

Some more information: If I clear cache from Drush, then run this:

drush eval 'print_r(entity_get_info("file"));'

I can then see the "type" field in schema_fields_sql. If I then go and clear cache from within Drupal admin/content becomes unreachable. I run entity_get_info("file") again and the "type" field has disappeared from schema_fields_sql.

sigh..something goes really wrong there

Enabling any other module results in file entity info becoming corrupted, i.e. losing the "type" field and therefore resulting in the "Missing bundle property on entity of type file." error when viewing content with a file field or accessing admin/content.

Clearing cache from Drush rebuilds file entity info correctly.

Although it was always file entities that caused my site to crash/white screen, I actually traced the issue back to entity_uuid module.

I am using entity_uuid to add uuid support to custom entities. I found that when I disabled this module the file entity info array would always be created correctly (not just sometimes). Looking into it, I noticed that entity_uuid was done some crazy stuff in entity_info_alter(). I removed this module and added UUID support directly to my custom entity module.

For anyone else getting this error, I'd have a look at any modules you might be using that implement hook_entity_info_alter() and see if they are the cause of the issue.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, file_entity_schema_field_type-1569952-13.patch, failed testing.

Status:Needs work» Postponed (maintainer needs more info)

We still shouldn't have to add this 'twice': once via hook_entity_info_alter() and once via the hook_schema_alter(). Not sure what we can actually do or if this is just manifested with random bugs with other modules.

Status:Postponed (maintainer needs more info)» Closed (cannot reproduce)

I haven't been able to reproduce this on new or existing sites with File entity installed.

From the previous reports and the lack of new reports, it sounds like this issue is caused by bugs in other modules which seem to have been fixed.