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)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tswaters’s picture

After 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.

tswaters’s picture

When 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.

/**
 * Implementats hook_module_implements_alter()
 * Ensure the hook for media_browser_plus_file_presave is unset
 *
 */
function media_browser_plus_helper_module_implements_alter(&$implementations, $hook) {
  // see if media_browser_plus's hook for presaving the file exists
 if ($hook == 'file_presave' && isset($implementations['media_browser_plus'])){
    // if so unset it so we can replace with our own version
    unset($implementations['media_browser_plus']);
  }
}

/**
 * Implememnts hook_field_attach_presave()
 * Media browser plus has problems when multiple file types are present.
 * Same as media_browser_plus_file_presave but has extra checks for finding tid
 */
function media_browser_plus_helper_file_presave($entity) {
  // the tid is not where we expect it
  if (empty($entity->field_folder[LANGUAGE_NONE][0]['tid'])) {
    // we don't even have the field_folder - set to root
    if (empty($entity->field_folder[LANGUAGE_NONE])) {
      $root = media_browser_plus_get_media_root_folder();
      $entity->field_folder[LANGUAGE_NONE] = array(array('tid' => $root->tid));
    }
    // weird case with multiple file types, set up the field_folder right
    else {
      $tid = $entity->field_folder[LANGUAGE_NONE];
      $entity->field_folder[LANGUAGE_NONE] = array(array('tid' => $tid));
    }
  }

  // Ensure file is stored in the appropriate folder.
  $folder = taxonomy_term_load($entity->field_folder[LANGUAGE_NONE][0]['tid']);
  $new_path = file_stream_wrapper_uri_normalize(file_uri_scheme($entity->uri) . '://' . media_browser_plus_construct_dir_path($folder) . '/' . basename($entity->uri));
  // Only move file if necessary.
  if ($entity->uri !== $new_path) {
    media_browser_plus_move_file($folder->tid, $entity, FILE_EXISTS_RENAME, FALSE);
  }
}
das-peter’s picture

Status: Active » Postponed (maintainer needs more info)

Any 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.

bennybobw’s picture

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

I 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.

bennybobw’s picture

The 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.

bennybobw’s picture

Status: Needs work » Needs review
FileSize
651 bytes

Uploading a patch that sets the default value explicitly. I tested this with private files enabled and disabled.

junaidpv’s picture

My experience is same as comment #5 and patch from #6 is working for me.

  • das-peter committed a0f5e63 on 7.x-3.x authored by bennybobw
    Issue #2215183 by bennybobw: unable to specify media folder on upload.
    
das-peter’s picture

Status: Needs review » Fixed

Just 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.