Hello,

With MBP installed, is it still possible to use the file widget in content type file fields, and have the uploaded files automatically saved to a custom file directory?

This is not working for us. Files keep getting saved to Media Root, ignoring the File Directory we specify in the content type.

Reference: I asked this question in the Post-Installation forum but no one answered. The title is "Upload and Save Media (Both Attached and Not Attached to Content Type)". Hope it's ok to repost the question here.

Background:
We have MBP installed and it's working very well for the 3 site administrators. However, our manager does not want the users/content creators using the media selector widget. He doesn't want them to see the custom file directory structure nor to explicitly save their files in any directory. They also don't need to reuse files at this time.

Thank you,
Ann

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

shortspoken’s picture

I am having the exact same issue. With MBP enabled, the "file directory" settings in any image or file field is not recognised. Disabling MBP solves it. But I would love to use MBP AND still being able to set a file directory, as the media selector widget is not always needed and wanted.

Media 7.x-2.0-alpha3
MBP 7.x-3.0-beta2+4-dev
File Entity 7.x-2.0-alpha3

deanflory’s picture

I've just come to this realization as well, trying to figure out where my Default Images for an image field (imagefield) were being saved and where the hell the setting was for changing that. So it appears Media Browser Plus is overriding those things and thus is not usable as it basically only lumps everything into one folder and is not as customizable as setting the upload path for each field, which, in my instance involves a path with user IDs in it which creates a logical folder structure.

Disabling.

Plus I'm not even sure I need Media Browser at all with IMCE installed and enabled, so I might be disabling it as well.

After all this, I'm not even sure who would use this MBP module.

Pere Orga’s picture

Version: 7.x-3.0-beta2 » 7.x-3.x-dev
Category: Support request » Bug report
Status: Active » Needs review
FileSize
708 bytes

This patch solves the File (Field) Paths incompatibility for me

das-peter’s picture

Category: Bug report » Feature request
Status: Needs review » Needs work

I don't think just skipping the presave helps.
It's more like we need a way to evaluate the give path and assign the related folder term to the file.
Just skipping the presave leaves an "orphaned" file in file_managed because how should MBP know that a file was handled by another module / was stored to a specific path when there are no indicators of that.

Pere Orga’s picture

Thanks das-peter

You are right, and now I am concerned about the current implementation of hook_field_presave(). I'm wondering why Media Browser Plus has to interfere with all file uploads, even in the fields where MBP is not used.

Btw I just noticed I submitted the patch in a wrong issue - this was not related to File (field) paths module originally.

das-peter’s picture

File Entity / Media and thus MBP don't aim to handle specific fields. It's built to deal with all managed files. Which means all files in the files_managed table are automatically handled.
The main thing that MBP does is to integrate these file entities with a taxonomy vocabulary - and mirrors this with the file system.
You can disable this file system integration and I guess that way the settings from the fields should be kept. While you're still able to use the folder organization via taxonomy terms.

Pere Orga’s picture

Thanks, I need to do some reading and I will look into it.

kreatIL’s picture

I can confirm that very same behaviour with MBP enabled. Patch #3 only works for files, not for images.
Images are directed into the folders specified by field settings when I disable "Create folders in filesystem" at admin/config/media/media_browser_plus_settings.

das-peter’s picture

Just thought about this more.
How about being able to define a MBP folder for those file fields?
Similar to beeing able to define an upload folder for those fields. You could select the Media Folder - that way you could even match the upload folder and the MBP folder.
And it would keep Media Root "clean".

The last submitted patch, 3: media_browser_plus-file_field_paths-2158869-3.patch, failed testing.

nixar’s picture

Using 7.x-3.0-beta3
This problem persists to this day and is a serious problem when you have a mix of files managed via MBP and others that are not and using file_field paths.

To summarize the behavior, files that are handled by MBP need 'Create folders in filesystem' to be enabled.
Files that are not handled via MBP need it to be disabled.
If you have both, you need to turn it on/off.

Is it confirmed to be fixed with the latest dev version (7.x-3.x-dev dated 2015-Oct-29)?

Edit: It looks like it

rajmataj’s picture

I'm seeing this issue with Webform as well. If you specify a place to save uploaded files in a webform, as long as you have 'Create folders in filesystem' set to a directory, it will override the webform location, putting everything in one place. Seems like too heavy-handed of a setting but unfortunately for my client, they have hundreds of files already uploaded which we don't want to mess with. Would be ideal to be able to choose when to enforce this setting, specifying which file fields to use it on.

I too can confirm that the latest dev (dated 2015-Oct-29) fixes this issue to a usable degree. Am really looking forward to a stable release with this change.

Anybody’s picture

May I push this issue and ask if this is solved in the current stable release and if yes, how to configure MBP and filefield to put the files into specific MBP directories when using a normal file field?

interdruper’s picture

If the target field has set the default upload directory and it exists in the Media Folder tree, the following patch selects that directory in the folder list inside the upload form.

In this manner, a default directory target is presented to the user, mitigating the number of files that are uploaded to the 'Media Root' or other directories that the user may select.

In our case, this patch also mitigates issues like #1488778: Unable to generate the derived image located at public, #1109312: Image derivatives (image cache files such as thumbnails or custom styles) are not created when clean URLs are enabled when using Media Browser Plus.

interdruper’s picture

Small fix to the previous patch: $form['#options']['file_directory'] may be not defined.

LauraRocks’s picture

I have this same problem with two different scenarios, both in same site. One is that we import content from social media sources, and would like to see them going straight to the right folder during automatic creation. And the second one is that we allow anonymous users to add content, but don't want them to use the MBP, so we have a basic image widget for them. I can say that the upload goes nicely to the right folder with the latest beta4-version, but the MBP Browser doesn't recognize the images being in the right folder. So in the physical folder structure everything is fine, but in "MBP folder", the files are in the root, making the MBP view very clogged. And when I then go and drag the file in the MBP browser to the right folder (where it actually already is!!!) it just moves it and renames it with a new "_0"-name.

Is there something obvious that I am missing here? I used the patch provided in #15, but it didn't help.

ann b’s picture

Status: Needs review » Needs work

I'm getting the same results as #16. The file is saved in the correct folder specified in the core File Directory field in the content type, but MBP shows the file in Media Root.

Field Type: File

Field Widget: File

Core File Directory Field: media/blogs

Drupal version: 7.51

MBP version: 7.x-3.x-dev -- Date: 2016-Oct-22

MBP Patch applied: #15

interdruper’s picture

@LauraRocks, @ann_b, could you please try the following patch #18?

I think that the folder selection element was not properly injected in the dialog, and that is the origin of the problem. The patch also extend the feature to the 'form_file_entity_add_upload' dialog (for single-valued fields)

ann b’s picture

I'm afraid I get the same results.

  1. reversed patch #15
  2. installed patch #18
  3. cleared all caches
interdruper’s picture

@ann_b, you mentioned that you are using the 'File' widget. The #18 patch only modifies the dialogs used by the 'Media Browser' widget, that is the widget introduced by the Media module and customized by the MBP module. The 'File' widget is provided by the core File module. And it should preserve the directory field.. does it work if you disable the MBP module?

ann b’s picture

File Widget
Both patches #15 and #18 fix the problem where the files were always stored in Media Root. Now the path in the file directory field, provided by the file module, is respected. Thank you! This alone is a big improvement.

admin/content/file
MBP shows the file in Media Root folder. But the file is actually in Media Root/blogs.

*

I disabled MBP and uploaded the file. It was correctly stored in media/blogs.

*

This may indeed be a separate problem. The view in admin/content/file is having trouble with files uploaded with the file widget. I can open a separate issue if it would help.

LauraRocks’s picture

I tried the patch in #18, cleared cache and added a node that had the normal core "image widget", and the problem persists, still the file is shown in MBP in the root folder when it actually is in the right sub folder.

interdruper’s picture

@LauraRocks, the #18 patch only modifies the dialogs used by the 'Media Browser' widget, that is the widget introduced by the Media module and customized by the MBP module. If in your field the 'File' or 'Image' widget is used, the MBP module and the patch do not influence.

It is a common confusion to consider MBP as a 'general-purpose server file browser'. MBP only will see properly located those files uploaded by the Media widget when MBP is installed. This is because the relationship between file entities and folders is handled thru an additional folder field only filled by MBP, not by core modules. When that folder field is empty, MBP will show the files as located in the root folder, even if they are physically located in sub-folders.

interdruper’s picture

This is a revision of patch #18: selected media folder was not properly carried to the last multi-step form.

LauraRocks’s picture

Ok, thank you for clarification, now I understand. The problem in our site is that there has to be a mix of images loaded both with core widget and MBP widget. I have to come up with something else for this scenario.

So I'll focus now on the other scenario on our site, which is "importing content from social media sources, and would like to see them going straight to the right folder during automatic creation" where this patch should help, I assume, because there I can use the MBP widget in the content type. So I changed the widget type, applied patch #24 and tried again, but still the same. Even though the widget is "Media Browser", the uploaded image is shown in the root folder (but correctly placed in the right folder).

interdruper’s picture

@LauraRocks, the patch only applies if the files are loaded and saved thru the upload dialogs. I guess that your importing process from social media sources uses Feeds or any other bulk importing method, so the dialogs are never called.

If this is your case, you would need to fix the images loaded from social media during the importing process or after importing them, programmatically filling the 'field_folder' that MBP uses with the proper folder taxonomy term . I have a drush command for this, I could provide it in form of sandbox if you are interested, when I find some time.

LauraRocks’s picture

Oh yes, so both my cases where out of scope for this issue, sorry for that! I will need to get this somehow done, so that the MBP wouldn't consider everything else (that is not handled by it) to be in the "root" folder. Either by programmatically when they are added, like suggested, or then limiting the root folder view for MBP. Those social media images and images that are loaded through core image widget are never reused in the site anyway, so they don't need to be in the MBP view.

But thank you for your help in understanding the issue!

ann b’s picture

FileSize
24.44 KB

The original problem was that when using the file widget, files were automatically stored to Media Root and ignored the core file directory path set in the content type. I tested beta4, without any patches, and this has been fixed. #11 and #12 reported the fix was in dev (dated 2015-Oct-29), and #16 also saw the fix in beta4.

*

The next problem is that though the files are stored in the correct folder, the MBP view shows these files (uploaded via the file widget) in the Media folder. I agree with #9. We can add a couple of MBP fields to the file field settings within the content type:

file field settings

Then in the presave if we don't see the folder field set, we can just add it unless the user has selected to bypass MBP (by unchecking the above checkbox). Here is some stub code. The image above was created with stub code. I haven't tried adding a column to a drupal table and storing field values there.

/**
 * Implements hook_file_presave().
 */
function media_browser_plus_file_presave($entity) {

  // MBP folder processing is skipped if:
  // - Manually requested by adding the property mbp_bypass to the file entity.
  if (!empty($entity->mbp_bypass)) {
    return;
  }

  // If not using the media widget, set the folder as specified in the content type.
  if (!isset($entity->field_folder) && !isset($entity->migrate)) {

    $folder_tid = 100; // todo - get $folder_tid from content type

    if (isset($folder_tid)) {
      $entity->field_folder[LANGUAGE_NONE] = array(array('tid' => $folder_tid));
    }

  }

  // Set appropriate default folder if necessary.
  if (empty($entity->field_folder[LANGUAGE_NONE][0]['tid']) && !isset($entity->migrate)) {
    $root = media_browser_plus_get_media_root_folder();
    $entity->field_folder[LANGUAGE_NONE] = array(array('tid' => $root->tid));
  }

  // Ensure file is stored in the appropriate folder.
  if (!empty($entity->field_folder[LANGUAGE_NONE][0]['tid'])) {
    $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, NULL, FALSE);
    }
  }

}

*

The next problem is that whatever is decided, we need documentation. I propose adding a note to the project page explaining which widgets are supported, and when custom code (if any) will be required. Please share your thoughts.

Sneakyvv’s picture

I had the same issue using Webform like @rajmataj said. I created a patch and went searching for the appropriate issue to post it to. Turns out I was already using the patch from @interdruper's in #2158869-24: MBP, File Fields and the File Widget.
Like @das-peter suggested in #2158869-4: MBP, File Fields and the File Widget, my patch does evaluate the path and auto-attaches a folder tid for files which are located within the media folder.
The difference with @interdruper's patch is that it takes care of file fields which do not use the MBP browser (so no folder is selected via @interdruper's injected select), but if the file field has an upload folder set within the media root folder, then the folder term id will be set automatically, making the file appear in the MBP browser in the appropriate place.

Sneakyvv’s picture

I noticed a few flaws in the previous patch, which have now been fixed.

  1. Since the media root term might not match the actual folder, an extra kill switch is needed
  2. Avoid strict warnings about passing arrays by reference