Community

Solving Drupal's local file management problem

The problem

The lack of a simple universal local file management solution (images, documents) that will allow the user to:

  1. Select files uploaded through a file/image field in the WYSIWYG
  2. Select files uploaded through the WYSIWYG in a file/image field.
  3. Ability to manage files through a file browser very much like Media 2's Views enabled file browser.
    1. Tagging: This eliminates need for file structure which make it invisible since it's arbitrary and confusing once you start using an image uploaded in a field on a Press Release in the body of a Page.
    2. Search for files (file name, tags, type)

Additional considerations

  1. When selecting a file for a field, the file browser should only show files that are allowable per the field's definition. (e.g.: Image fields should not show PDFs)
  2. Image field settings such as minimum and maximum height and width do not need to be enforced while browsing. While it would be nice if it was enforced when the file is selected, it's OK that this happens during form validation.
  3. File attributes such as title, alt, cropping do not need to be stored globally.

Possible solutions

Media 2

The Media module is too complicated for basic, local file management. The problem the Media module is inherent in it's scope, "a file browser for the internet," as it lacks the most basic of file insert and file link workflows. Or if the option to create these workflows does exist, it's impossibly complicated to figure out.

See this comment for elaboration.

IMCE

IMCE can serve as the back-bone of the file management solution if is extended with the following modules:

  1. File searching
    1. IMCE Tools: http://drupal.org/project/imce_tools
  2. Selecting files for fields (one or the other module)
    1. FileField Sources: http://drupal.org/project/filefield_sources
    2. IMCE for FileField: http://drupal.org/project/imce_filefield (Seems to duplicate functionality that FileField Sources provides. I've logged this question for the maintainer (#1857110: Duplicate functionality to FielField Sources module?).

This solution doesn't accommodate the ability to tag. This isn't the end of the world. Using good file naming conventions and the search utility provided by IMCE Tools, content creators can effectively manage files in a "flat" (no folders) file structure. This begs the question: Do we need the "Navigation" frame in the IMCE window?

The implementation of file searching in IMCE Tools is lacking per this case (#1649274: Make search results clickable) and screenshot below. If the patch is applied, I can see how this might work, but will the link select the image in the main IMCE file list or will it select and close? We would want the former to mimic the workflow of selecting a file in the main window.

Without the ability to tag images and without a good search utility, there was the thought that we could eliminate the ability to upload a file in the node edit form and instead force the user to upload through the IMCE popup window. Doing so would make the image upload workflows exactly the same between fields and the WYSIWYG. This workflow would provide the ability for users to properly place images in the directory structure.

The only problem with this is that file size (width/height) enforcement would not occur at the time the user is upload the image, rather it would occur that the time the user saves the node form. This wouldn't be a problem for the Feature Image field because those images are scaled down from any size image. But this would be a problem where the exact size is needed.

Asset

There is an Asset module and series of modules, but it really seems out of date. Considering that some big names in Drupal were involved in in it years ago and no longer are suggests that it's not a great solution anymore. I'm also concerned by it's approach of creation of a new "media asset" instead of using Field Entity as an API to the native file field. Media also use have this in Media 1, but deprecated it in Media 2.

Comments

The Media module is

The Media module is complicated, but I believe it does what you are looking for.

Jaypan We build websites

I should have elaborated on

I should have elaborated on why Media 2 isn't working for me. The following is a list of just the more recent aggravations

WYSIWYG:

1. Unexpected results when linking to a local file. Sure, you can insert a file by clicking on the Media insert button and that link that is inserted will be the name of the file, but this an odd workflow for content editor who rightfully expects a) to be able to click on the Link button and access the media browser and b) once the file is selected, the text that had been highlighted in the editor then be linked to the file that has been selected. If you instead click on the Media insert button and then select the file you want to link to, the highlighted text is wiped out and replaced with the file name. Why is there no link to the Media library through the link button?

2. Being asked to choose a format. I understand that being asked to choose a format (Default, Teaser, Preview) makes sense if you've selected an image to embed into the Body, but it makes little to no sense when you want to simply link to an JPG or PDF.

Asset module is being actively developed again

Asset module is being actively developed again. Since it requires Entity module, I can only assume that an Asset is an instantiation of an entity (Image, Video, Document). It has a dependency on the CKEditor module (as opposed to WYSIWYG).

There is a case in the Media module queue which discusses the idea of pulling Asset code into Media. It also points out an original concern about the module, "Creates its own new entity type (asset) rather than re-using managed files, which means inter-operability with other modules is a problem. Also doesn't support anything that's been uploaded via file or image fields already prior to install. Assets no longer available after uninstall." http://drupal.org/node/1673750

nobody click here