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.
I updated the module to 2.0-unstable7 and all of my pdf files (documents) are of type undefined. This is only for existing file types. New uploaded files get the correct file type. I did a manula cron run just in case but it didn't change anything. Images seem to work fine btw (have no video/audio files).
This breaks nearly all my views which filter for different file types. I have no media module running so this should be file_entity specific.
Comment | File | Size | Author |
---|---|---|---|
#27 | media-update_dependencies-1846518-27.patch | 394 bytes | azinck |
#17 | 1846518_install.diff | 470 bytes | arthurf |
#15 | upgrade_sequence.diff | 591 bytes | arthurf |
#5 | file_entity-1846518-5.patch | 533 bytes | tobiasb |
Comments
Comment #1
ParisLiakos CreditAttribution: ParisLiakos commentedCheck the mimetypes under document file type. Does it include the one of your pdf's?
Comment #2
grossmann CreditAttribution: grossmann commentedYes, there is the mime type "application/pdf" under document file type (no other found in the mimetype list). And new documents get the correct file type so this has to be a problem between version updates (I updated from 7.x-2.0-unstable6).
Comment #3
ParisLiakos CreditAttribution: ParisLiakos commentedThats weird.
If you resave an existing pdf file with undefined type, does it get the correct type after saving?
Comment #4
grossmann CreditAttribution: grossmann commentedNope, still undefined.
Comment #5
tobiasbAll files with the type "application" in file_managed needs a update to "document".
Comment #6
grossmann CreditAttribution: grossmann commentedTested and works.
Thanks for this fix.
Comment #7
ParisLiakos CreditAttribution: ParisLiakos commentedNot 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
Comment #8
Devin Carlson CreditAttribution: Devin Carlson commentedMarked #1869948: Document loss of "Application (multipurpose)" or provide a way to fix this as a duplicate.
Comment #9
Alan D. CreditAttribution: Alan D. commented"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.
Comment #10
DamienMcKennaAfter upgrading a site from unstable3 to unstable7 I was left with the following data in {file_managed} with an 'undefined' type:
I can remove the first file, fix the videos, but what should be done with the gmap_markers.js file?
Comment #11
ParisLiakos CreditAttribution: ParisLiakos commentedsince 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
Comment #12
arthurf CreditAttribution: arthurf commentedI 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?
Comment #13
Alan D. CreditAttribution: Alan D. commentedSteps 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. :(
Comment #14
arthurf CreditAttribution: arthurf commentedWith 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.
Comment #15
arthurf CreditAttribution: arthurf commentedIn 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.
Comment #16
ParisLiakos CreditAttribution: ParisLiakos commentedwhy not 7201? thats when we get the type field.
if folks can verify that this works, i am happy to commit it
Comment #17
arthurf CreditAttribution: arthurf commentedHere's a reroll
Comment #19
bbinkovitz CreditAttribution: bbinkovitz commentedI was able to apply this patch cleanly.
#17: 1846518_install.diff queued for re-testing.
Comment #21
ParisLiakos CreditAttribution: ParisLiakos commentedIt fails because its in wrong project:)
Comment #22
ParisLiakos CreditAttribution: ParisLiakos commented#17: 1846518_install.diff queued for re-testing.
Comment #23
bbinkovitz CreditAttribution: bbinkovitz commentedI was able to reproduce the problem and verify that the patch resolves it.
Comment #24
cosmicdreams CreditAttribution: cosmicdreams commentedI can also confirm RTBC
Comment #25
ParisLiakos CreditAttribution: ParisLiakos commentedthanks a lot for testing and arthur for path.committed!
http://drupalcode.org/project/media.git/commit/77521a8
Comment #27
azinck CreditAttribution: azinck commentedMedia'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()?).
Comment #28
azinck CreditAttribution: azinck commentedComment #29
ParisLiakos CreditAttribution: ParisLiakos commentedit 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...
Comment #31
commonpike CreditAttribution: commonpike commentedStrange - 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 hereAssured me everything that had type 'default' had to be 'document' in my case, soSeemed 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.