Document file types are undefined after module update

Check the mimetypes under document file type. Does it include the one of your pdf's?

Thats weird.
If you resave an existing pdf file with undefined type, does it get the correct type after saving?

All files with the type "application" in file_managed needs a update to "document".

Not exactly..not all of those file types are documents..a check whether its mimetype is in the document type would be better instead of unconditionally set it to document

Marked #1869948: Document loss of "Application (multipurpose)" or provide a way to fix this as a duplicate.

"not all of those file types are documents" .. a website where I just fixed this was using videos here.

Is there anything to prevent users from allowing multiple types here and if so, merging these to existing videos / images / whatever would potentially mean that the display settings (yuk.. and fields) are potentially lost...

Personally a simple update notice about creating this type in a manually defined module and not setting this to undefined. Then adding an error warning about an undefined type in the site report linking to a simple page on DO explaining the process of defining the type. I assume that we could use entity info alter hooks for this.

After upgrading a site from unstable3 to unstable7 I was left with the following data in {file_managed} with an 'undefined' type:

• A file record with uid=0, empty filename, empty uri and filemime of "application/octet-stream". I've no idea where this came from.
• A vimeo video that has the filemime of "video/vimeo".
• Six youtube vieos that have the filemime of "video/youtube".
• The file gmap_markers.js from the gmap module that has the filemime of "application/x-javascript".

I can remove the first file, fix the videos, but what should be done with the gmap_markers.js file?

since application/x-javascript does not belong to any file types, then it should stay undefined type..
Maybe after this is in: #1260050: Provide administrative UI for adding/removing file types you could create a new file type..lets say JS and assign this file there

I just tested a file_entity unstable6 to unstable7 upgrade without issue. From reading this issue I'm guessing file_entity_update_7202() is why this is happening for some people. There is another update function file_entity_update_7101() which looks like it tries to fix something very similar.

Can anybody else reproduce this issue?

Steps to replicate, use "Application (multipurpose)" for say videos and documents and run the updates.

Looking back through the update scripts:

file_entity_update_7101() that uses the first part of filemime to create the type. This could have issues as it should only update known file entity bundles. i.e. "message/rfc822". Bundle message is invalid. Or I guess "text/html" would also create an invalid bundle / undefined file type too.

file_entity_update_7202() '' > 'undefined'. Again, no such bundle

But to the issue at hand... When dropping a file type, I guess an update like file_entity_update_7101() is required, that only updates to known mime types. Other mime types should default to undefined.

The big issue with this is that the file type undefined is currently fairly unusable as there is no corresponding undefined bundle. :(

With a clean install of 1.2 migrating to 2.x I see this behavior for all of my file content. I'm marking this as critical as it is a blocker for any 2.x release.

In terms of the actual data, if I do the file_entity updates before any of the media updates, the data in file_managed is correct. Making all of the media 720X updates depend on file_entity 7204 seems to handle at least the data correctly.

why not 7201? thats when we get the type field.
if folks can verify that this works, i am happy to commit it

Here's a reroll

I was able to apply this patch cleanly.

#17: 1846518_install.diff queued for re-testing.

It fails because its in wrong project:)

#17: 1846518_install.diff queued for re-testing.

I was able to reproduce the problem and verify that the patch resolves it.

I can also confirm RTBC

thanks a lot for testing and arthur for path.committed!
http://drupalcode.org/project/media.git/commit/77521a8

Media's 7200 update was released before File Entity's 7201 update, so it's possible for someone (like me) to have already run media_update_7200(). The current code specifying the dependency does not enforce the requirements in this case.

I suggest the following patch which is more specific to ensure that file_entity_update_7201() gets run before media_update_7208(). That said, I'm not sure if there are other order dependencies that we should be concerned about in update hooks for file_entity and media (I'm wondering about file_entity_update_7202() ... might it be better to run it after media_update_7209()?).

it was 7208 before the patch above that commited..so i changed it to 7204, since unstable6 was released with 7202 and 7203 is empty
http://drupalcode.org/project/media.git/blobdiff/7c36da077ab8d062afc1a7b...

Strange - 4 years later, I update from Media 1.6 to Media 2.6 and exactly this problem appears. Everything else seems fine sofar.
All updates between 7200 up to 7227 have run.

A quick look here

mysql> select distinct filemime, type from file_managed ;

Assured me everything that had type 'default' had to be 'document' in my case, so

mysql> update file_managed set type=‘document’ where type=‘default’

Seemed to work.

[EDIT] actually, I hadn't noticed the media module upgrade had installed a module for me that does exactly that, at /admin/structure/file-types/upgrade. It should get a 'configuration' cog wheel in the module listing after you've enabled permissions for the admin user to administer file types, which takes you to a UI to upgrade legacy file- and mimetypes to the new setup.