media_fid_illegal_value error when adding media to an entity

subscribing

I was getting the same error. I determined that, somehow, the Media File Selector widget's settings for allowed types for my Multimedia Asset field was returning an empty array (even though the edit page for that field (Home › Administration › Structure › Content types › Yr. Content Type › Manage fields) indicated that the Image type was allowed. Simply going to the edit page for that field and hitting Save fixed the problem for me.

I'm not sure what caused the problem in the first place, and didn't get a chance to see what was going on in the database before I was able to resolve the situation, but it clearly exists. If I see the problem again, I'll try to get more info.

I'll confirm. I had the exact same issue, and the exact same process resolved it.

I can confirm the same process. I hadn't experienced it before because I always configure the field to add help text after creating it with drush, but was testing in a sandbox today and ran into it.

This fixes it for me.

confirmed this fixes the issue. thanks!

I fail to see what's actually getting fixed by this?

When I have a media field, I added some debugging to the current code (no patch applied):

function media_field_validate($obj_type, $object, $field, $instance, $langcode, $items, &$errors) {
  debug($instance['widget']['settings']['allowed_types']);
  $allowed_types = array_keys(array_filter($instance['widget']['settings']['allowed_types']));
  debug($allowed_types);

First debug:

array (
  'image' => 'image',
  'audio' => 0,
  'video' => 0,
  'default' => 0,
)

Second debug:

array (
  0 => 'image',
)

This seems to already be the correct value and I don't get any errors.

ah yes, i see what's going on. the issue is if the user doesn't go through to the field settings after the initial creation. this patch incorrectly passes through the array keys without filtering them, and is thus overpermissive. i'm not sure if this should be considered user error or a drupal core bug, but unfortunately in either case, it's out of the domain of this module.

Hi Aaron,

I'm not sure this is fixed. I keep running into it myself and I'm unclear what the suggestion is to stop the error from happening.

How is roobys patch applied (by a noob) and does it work for the 7.x-2.x branch? Thanks. (edit: fixed by installing the 7.x-1.x branch, seems to work)

Seems to relate to the "other" file type. I can reproduce this issue as follows (using Media 7.x-2.0-unstable1):

• Enable Media and Media: Youtube.
• Create a new content type and add a multimedia asset field. Configure the field to allow image, video, and other file types.
• Add a new piece of content, selecting a youtube video for the media field. Content is created without error.
• Add a new piece of content, uploading a .pdf file for the media field. When submitting, the error message media_fid_illegal_value appears.

Same issue for me, on 7.x-2.0-unstable1.
In fact, the validator is trying to find the type "application" in the variable $allowed_types.

Testing the latest DEV version (7.x-2.x-dev - 2011-Aug-26), I experience the same issue when trying to upload a PDF as 'other'. The changes in patch in #6 don't seem to make a difference: the error still occurs. I'm using Drupal 7.8.

Actually, i am using a workaround but i am not sur it's the best approach.
In a custom module, i write a hook_install and i add a media type in the table. (Like in the hook_install the media module)

module_load_include('inc', 'media', 'media.types');
  $types['document_pdf'] = new stdClass();
  $types['document_pdf']->name = 'application';
  $types['document_pdf']->label = "Document PDF";
  $types['document_pdf']->base = TRUE;
  $types['document_pdf']->type_callback_args = array(
    'match_type' => 'all',
    'mimetypes' => array('/^application/'),
    'extensions' => array('pdf'),
    'streams' => array('public', 'private'),
  );
  foreach ($types as $name => $type) {
    media_type_save($type);

    $bundle_settings = field_bundle_settings('file', $name);
    $bundle_settings['extra_fields']['display']['file']['media_small'] = array('weight' => 0, 'visible' => FALSE);
    field_bundle_settings('file', $name, $bundle_settings);
  }

A the moment, it works.

Updated issue summary.

Updated issue summary.

subscribe - same problem when I upload a PDF

I was getting the same error setting up MediaFront in a Linux sandbox and using a YouTube link. The same link worked on Windows localhost. I did two things:

1. I set up an "HTML5 Media" content type that I realized that Media Front now has. The media view uses this.
2. I did #3

This worked.

+1, got this error when trying to use Media:Other. I added a Media field to my content type, and chose Media:Other because this was going to be used for documents (PDF, doc, etc.) associated with a node.

I can upload a file, but when I then chose to upload a second file, I got the error, media_fid_illegal_value

#6: media-media_fid_illegal_value-1142630-6.patch queued for re-testing.

+1 for this issue. Clean install of D7.8 , tested on Apache, NGINX, PHP 5.3 and 5.2, MySQL 5.1. Created a new content type, and added a Media field to it. If you upload any file other than an image, when you submit you receive this error. No other information, just the error. I've tried rebuilding types, re-saving all of the Media settings pages, and poking around with everything I can possibly configure on the field.

If I visit: /admin/structure/types/manage/media/fields/field_asset/field-settings (that's field settings for my Media field), I get: "There is data for this field in the database. The field settings can no longer be changed." That's more or less what I expected, except that the field doesn't work.

So for me at least, Media module is completely useless for everything except images. Does anyone have a working instance of Media module for non-image content in D7-latest? What was your secret? Otherwise, someone should put up a big red blinking warning on the module summary page that it's fundamentally broken?

I hit this one too (attaching a pdf)

1) the patch is outdated ( the function appears to have moved)
2) var_dump( $instance['widget']['settings']['allowed_types'] ); die();
in mediafield_field_validate (in modules/mediafield/mediafield.module)

array
  'image' => string 'image' (length=5)
  0 => int 0
  'audio' => int 0
  'video' => int 0
  'default' => int 0

hint ?

I had this issue while trying to select an FLV file using the media selector. The issue was resolved by editing my Content Type and checking the "Video" box in the Allowed Remote Media Types field.

This is a little bit confusing because I was not using remote media so I ignored this field. Apparently, this field is also relevant even when using local media.

Same here, trying to use .pdf files. Following #23 I enabled "Other" for Remote Media and it works. If that's working as designed the description for this field should change; very confusing indeed...

Same bug as #24, but i don't see where is the "Allowed Remote Media Types" field, maybe someone can help me on this.

It is probably in /admin/structure/types/manage/article/fields/field_media
Checking every boxes didn't fix the problem but I found that var_dump'ing() as in the comment #22 now brings:

array
  'audio' => string 'audio' (length=5)
  'image' => string 'image' (length=5)
  'video' => string 'video' (length=5)
  'default' => string 'default' (length=7)

but still this media_fid_illegal_value error.
I'm quite sure that is related to the fact that :
- the wysiwyg "standard" library does not show my PDF files
- the wysiwyg "views" library does show my PDF files
- the "select media" field "standard" library does show my PDF files
- the "select media" field "views" library does show my PDF files

I think something is wrong with file type-constraint handling (seems a bit like #1301774: Remove some legacy popup browser code)

Obviously !
PDF file are of type "application" in the {file_managed} table while allowed type are IN ('audio', 'image', 'video', 'default')

let's try this one :)
(roughly: activating the "default" file type allows any file type)

should I ?

#28: 1142630-28.patch queued for re-testing.

above is a workaround,

and for those who, like me, didn't searched/read before adding comment to this bug:
below are the bugs this one now depends on :
#1260050: Provide administrative UI for adding/removing file types
#1292382: Make it possible to create any number of custom File Types
#1037234: 'Allowed file types' rubric in wysiwyg upload interface is wrong
(of course not exhaustive)

On this workaround, by drzraf... HOW do I try to put it in place? Do I use ssh to put it in place, or copy/paste it somewhere, what?

Can anybody shed a little light on the patch. I'd like to see if I can get this thing working (same error, regardless of what I do: media_fid_illegal_value error). And I've been trying to upload MP3 files. Odd thing is - at least once or twice, they get loaded into the library, but the content does not get created.

kjv1611, I would say, man -a man ssh patch git git-apply + http://drupal.org/contribute/development

Patch #28 seems to point to a mediafield module instead of the media module. Is this correct?

Brain dumping here for my own sanity as well as anyone else who is interested.

From what I can tell, the error relates to the following bit of code in media/includes/media.fields.inc

function media_field_validate($obj_type, $object, $field, $instance, $langcode, $items, &$errors) {

  $allowed_types = array_keys(array_filter($instance['widget']['settings']['allowed_types']));

    // @TODO: merge in stuff from media_uri_value
  foreach ($items as $delta => $item) {
    if ($item['fid'] == 0) {
      return TRUE;
      //@TODO: make support for submiting with just a URI here?
    }
    $result = db_select('file_managed', 'f')
      ->fields('f')
      ->condition('fid', $item['fid'])
      ->condition('type', $allowed_types, 'IN')
      ->execute()
      ->fetchField();
    if (!$result) {
      $errors[$field['field_name']][$langcode][$delta][] = array(
        'error' => 'media_fid_illegal_value',
        'message' => t('%name: illegal value.', array('%name' => t($instance['label']))),
      );
    }
  }
}

What I think it is doing is bringing in all the allowed types into the $allowed_types array. It then queries the file that has been uploaded by pulling it from the db using its fid. It then tries to compare its type and see if it's in the $allowed_types array. All that is in this array is ...

Array ( [0] => image )

Now I've been trying to get it to work with mp3 files, and as they are listed in file_managed with a type of "audio", they are never going to be allowed.

So, what do we know
- that the allowed file types are being saved, because we can go back in and view them in the settings.

Looking at what is passed in in the $instance variable, we can see that the allowed file types are actually there, its the bit that converts the keys of that array into an array itself that is at fault.

Nearly there!

Looks like the line

$allowed_types = array_keys(array_filter($instance['widget']['settings']['allowed_types']));

is at fault.

array_filter has no callback function specified, so it'll remove anything that equates to false (I think), which is probably why everything is being removed except "image".

Removing array_filter function from this line and the file can be successfully stored. What knock on effects this will have I'm not sure. The investigation continues...

#6: media-media_fid_illegal_value-1142630-6.patch queued for re-testing.

I never tried the latest patch, but I did manage to get it workig on my test site.

I had been playing around with MediaElement and the Media + MediaFront combination.

Before, I had been following video tutorials, site-listed isntructions, etc, to get the Media + Mediafront to work. Well, it wasn't working correctly - giving the error this issue was created in reference to. However, this last time, I just charged at it with no insructions (no code changes anywhere), and was able to get it to work successfully.

I think the issue relates to (and you may be covering this in the code you're looking into) WHEN the user/admin/site designer/human being ;) sets up the file types for the Mediafront Preset or else for a field when creating the field... I'm not 100% sure, b/c I was just clicking and typing away, not really expecting anything, but thought I'd try. This go round, I found and set the file associations right up front, and then absolutely no issues whatsoever. I'm hoping I'll get time to setup another installation, and try this again just to be sure i have it down pat... if I do, I'll also try to remember to post the "1,2,3" instructions here for those interested..

In 7.x-1.x-dev (2011-Nov-21) I was able to get this error to stop by simply turning on the correct FIle Type in the particular Media field I was trying to upload to.

I encountered this error when trying to upload a video file to a media field. The issue is resolved by applying the attached patch, which then allows me to select the file types that can be uploaded to a particular field (the default only allows Images, I needed to check Video too). Before applying this patch, no checkboxes are provided to allow me to select additional file types to allow.

Note, this isn't an issue if you have a module that provides a remote stream wrapper such as the Media Youtube module.

One thing I just noticed on this again last night (12/14/2011) was that if I uploaded a file from my local computer via the Browse button, that seemed to work. If I tried to add a file from a web source (was direct link to the file from current/previous setup of the same site), it gave the "only allow images" error. I thought it interesting, b/c the file type is only set in one place, unless I missed something. Does it have to be set in one place for each add/upload method?

Getting this as well with media-7.x-2.x-dev (Dec 19) on a page node with a 'multimedia asset' field - trying to add a pdf uploaded from local machine. Got the media_fid_illegal_value on node save, but the file itself was correctly uploaded and is now in the library.

@millarJ - just confirming that your solution in post #35 fixed the issue in 7.x-1.x-dev (which is what this issue started with, and then changed, halfway though, much to the chagrin of anyone also using media_gallery, which doesn't support 7.x-2.x........).

Also confirming that this fixed my issue with flv files for 7.x-1.x-dev

#39 fixes my problems when uploading mp3-files.

#39 fixed the problem uploading PDF files. Now if only I could get them to display!

Hello,

We have the same Problem here, and i tried the patch #39 but the patch can not be applied because i think that there are some files missing.

can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/includes/media.fields.inc b/includes/media.fields.inc
|index 0e4d724..ee28bc7 100644
|--- a/includes/media.fields.inc
|+++ b/includes/media.fields.inc
--------------------------

when i look to the installed modules, i can only find media. Can it be possible that mediafield is missing? Because i can not find it installed ...? And I do not have the Files which should get patched.

@hiradi the patch in #39 is for the 2.x branch. 2.x is almost a complete refactoring of the media module code so a lot has changed.

Please file a new issue with a reference to this one.

Do you mean the field settings after adding the field to a content type? Because I definitely did that. I still get the issue too. The other thing I noticed is it says the file must be less than 0 bytes but it uploads anyway.

#35 worked for me to allow xls and zip files to be uploaded and displayed as links.

@thosmos: Please don't change the version like that. It already has a tag for backporting to 1.x. It also makes it harder for developers to find when filtering the issues.

It looks like #39 has been committed to the latest 2.x-dev (Feb-10), and resolves the main issue for me.

I did still get this error when:

1) I have a field that has a different "Allowed Remote Media Types" then the "Allowed File Extensions for Uploaded Files", probably a configuration issue, and fixing that for my field resolved this. See attached screenshots. Also, the attached file is a local file, not a remote file.

2) Selecting a file of a different type then allowed gives this error. IE: Selecting an image for an Audio field. A better error message would be more desirable here.

Oops, didn't mean to change the version.. changing back.

Would somebody please explain where "Allowed Remote Media Types" is mention under #23 - #25????

#39: media_fid_illegal_value-1142630-39.patch queued for re-testing.

#55: At least in 7.x-2.x, Allowed Rmote Media Types is found once you add a multimedia asset field to a content type - if you edit that field's settings in a particular content type, you'll see the check boxes - just a little ways past the 'allowed file extensions...' setting. If I read the discussion correctly, you need to make sure you enable the appropriate 'remote stream' type to match the 'allowed file extensions', even if the file isn't 'remote' in the sense of a YouTube or Flickr link.

Oh, and assuming this really should still be 2.x-dev, as per #52...

chiebert,
Thanks for explanation. I ended rebuilding drupal installation from start, but I kept old version, so I will check if I can find solution for this.

Having the same problem regardless of version. Have tried both Dev versions available on 2/25/2012 but get the same error when trying to add MP4 from library. Is there a work-around for this? The issue is stalling my project.

Hi, I'm not sure if we are talking about 7.1 or 7.2 version and I'm pretty lost but I got the same issue with 7.x1.0-rc3 version when uploading mp3 or video or pdf. Well anything but images actually.

So is the way around it to get 7.2 version and apply #39 patch ?
Will 7.1 versions get the patch as well ? or is #35 correction the correct thing to do ?

Well before trying 7.2 version, I applied #35 idea and It's working on 7.x1.0-rc3. Don't konw what it breaks though...

Hi all I had the same issue. could not locate the remote settings as mentioned in #23, tried the other cusotme fixes #3 and am unable to run SSH commands without applying to my host :( as per the how to patch URL help.

my fix for my site was

installed as per http://drupal.org/node/1168926 and after getting the error, created a 2nd field and am using a fields field type "file" and not "multiemedia asset".

both fields are available when i create new content and using the new field with fields field type "file" to upload from, the error msg has gone away and the media content submits...

I hope that makes sense, good luck everyone with the error, hope this helps someone.

I took a stab at this last week and here's the patch I've come up with against 7.x-1.x-dev and seems to work. In fixes

• Validation in media_field_validate() should only be for actual remote files and not uploaded files since those are validated by extensions. This logic is already enforced in the field settings.
• Adds a file_entity_file_is_local() to determine if a file is using a local stream wrapper or not.
• Adds additional conditions to the Media browser query to better enforce while local or remote files are actually selectable.
• Fixes the 'nice' error message isn't shown if a remote file isn't in the allowed types.

#64: 1142630-fix-media-field-validate.patch queued for re-testing.

Anyone on 7.x-1.x able to review the patch in #64?

Dave, what should I do if I am experiencing these same errors in rc3?
.PDFs and .MP3s :(

#62 - lafuenta could you please elaborate as to what you specifically changed to get rc3 working for .pdfs and videos? I'm not a strong coder

I was using 7.x-1.x-rc3. In order to test the patch, I downloaded the latest using git. (To be precise, git log tells me that e78bbae02df85c3d112db1c7a7890143fa6219f5 is the most recent commit, March 13.)

Disclaimer: I am just beginning to experiment with this module. I got the "media_fid_illegal_value" error and searched the issues queue.

I tried the patch from #64, and it seems to work. I created nodes with attached media .txt, .doc, .xls.

Then I installed the Devel module and applied the latest patch from #1198820: Support for Devel Generate in deprecated mediafield. (It seems that patch still works for the 1.x branch even though the issue has been moved to the 2.x branch.) It worked, but it seems to have added only PNG media, so it is not any more comprehensive than my manual tests.

This seems like a very promising project. I am glad I can help a little by reviewing the patch.

This has been committed to Git for both 7.x-1.x and 7.x-2.x:
http://drupalcode.org/project/media.git/commit/7a9ff99
http://drupalcode.org/project/media.git/commit/738a199