We're using the following modules :
- media 7.x-2.0-alpha3+12-dev
- file_entity 7.x-2.0-alpha3
- media_browser_plus 7.x-3.0-beta2+7-dev
When attaching media to an image field, or to a wysiwyg editor via 'add media' wysiwyg button, the media folder field shows up during step 1 of the file entity upload form, but setting it has no effect -- the file will always be saved to the root media folder. The following warning shows up in the error log when this happens,
Warning: Invalid argument supplied for foreach() in taxonomy_field_presave() (line 1888 of /root/modules/taxonomy/taxonomy.module).
I find that the last argument passed to taxonomy_field_presave should be a hash array but is really an array of numbers identifying the tid of the selected media folder... something like this:
$items = array(99)
When the cardinality of the field > 0 however, the select list does seem to work... the same debug code I added to taxonomy.module reveals the $items array looks something like this :
$items = array('tid' => 99)
--
If attached to a WYSIWYG, there doesn't seem to be a way to move the media to another folder -- any time you bring up the media dialog, the folder shows as 'select a value' and setting it to anything else has no effect. When attached to an Image field, the 'edit' form does work and you can move the image around.
The 'admin/content/file/list' will also allow for images to be moved from the media root folder, but if the image has been attached to a wysiwyg, moving it will break the image link (I think this is media being strange... it should be keeping tokens for images but instead I'm seeing markup with hard-coded src tags; we can go back into the node edit form, open up media dialog and re-save it to update the broken link if this happens)
Comment | File | Size | Author |
---|---|---|---|
#6 | media_browser_plus-folder-save-2215183-5.patch | 651 bytes | bennybobw |
Comments
Comment #1
tswaters CreditAttribution: tswaters commentedAfter playing with this I've come to the conclusion this relates to having multiple file types to choose from. I'm not entirely sure which modules can't handle this properly, but if I disable any custom file types we have (there is one), the initial media folder selection works.... still have the same problem with changing the media folder from within the wysiwyg 'add media' dialog, but I'm pretty sure that's been like that for a while now.
Comment #2
tswaters CreditAttribution: tswaters commentedWhen there are multiple file types available and the file_entity setting for "Skip filetype selection" is set, the file type defaults to 'undefined' and never shows the field form.
Because of this, when the hook_file_presave fires, the field_folder isn't in the format the function is expecting. I ended up fixing this in a custom module by unsetting the file_presave hook and creating my own which is pretty much identical except with extra checks around finding the tid.
Comment #3
das-peter CreditAttribution: das-peter commentedAny more information on this? I'd say I've a quite complex setup and can properly set the file type in the upload (plupload) form and in the "post processing" after the upload the field is available as wel.
Comment #4
bennybobw CreditAttribution: bennybobw commentedI just tested this out on a clean install with File Entity 7.x-2.0-beta1+16-dev, Media 7.x-2.x-dev, and Media Browser Plus 7.x-3.x-dev. The folder stays selected as long as I don't have private files set up in admin/config/media/file-system. As soon as I add a private files path, I start getting this error.
Comment #5
bennybobw CreditAttribution: bennybobw commentedThe media folder doesn't get saved on the file entity after it is uploaded. So if there are any steps between the file_entity_add_upload_step_upload and file_entity_add_upload_step_fields, the Media Folder field will not be set since form_builder() uses $form_state['input'] to set the values. For instance, in file_entity_add_upload_step_scheme, $form_state['input'] contains the scheme values, but not the folder values.
Comment #6
bennybobw CreditAttribution: bennybobw commentedUploading a patch that sets the default value explicitly. I tested this with private files enabled and disabled.
Comment #7
junaidpvMy experience is same as comment #5 and patch from #6 is working for me.
Comment #9
das-peter CreditAttribution: das-peter commentedJust pushed patch from #6 - I was even wondering if we could make
case 4:
to the default case - since the conditions would cover failures. But as of now I kept it as is.