Views: Provide a new "File browser" display type, and make it available when creating views of type "Files" (part of a bigger plan)

[klonos]

This is just a baby step towards a bigger plan, outlined here: #2718 (comment)

Over in #2718, @argiepiano mentioned this forum post where he documents how to mimic the image browser introduced with the Image Library (see #3297) in order to implement a generic, custom file browser/picker (the specific post describes how to do that for pdf files, but can be adapted for any type of file). That got me thinking the following:

The view creation wizard at views/add allows you to select what you would like the new view to show (content, files, taxonomy terms, etc.), and right below there is a section with 2 options:

• "Create a page" (selected by default)
• "Create a block"

I would like to propose that we add another option when "Files" (file_managed) is selected as the type for the view. We should then convert the steps outlined in that forum post mentioned above to be configuration options for that type of display. The type of display should be called "file browser" or "file picker":

[argiepiano]

This is an intriguing idea, but I'm unclear what the benefit of this display handler might be. Let's say you (a site builder) create a view and use this display handler to display all PDF files, and allow users to select a file. What do you do with the selected file? Pass it to Rules, perhaps? How?

Additionally, if you wanted to create a file browser/selection as a site builder, you can easily build a File view, and use VBO to select it. This would also allow you to pass the selected fid to a Rule.

To be clear, I do agree that file fields should have a core file browser/selection tool like images. But creating a new views display handler doesn't seem to be necessary to accomplish this. We could just provide a special view like core does for the Image browser.

An additional thought: while I've written views handlers aplenty, I've never created a views display handlers, but AFAIK, display types should be applicable to any and all views of all entities (nodes, files, users...) and beyond (e.g. views of modules and themes, etc). This proposed display type would only apply to views of File entities.

[klonos]

... I'm unclear what the benefit of this display handler might be.

One possible scenario is to create a file browser that allows specific media type(s) or specific file extensions when it comes to new files added to the respective file field, and to also restrict the addition of existing files to a specific "folder" or category of files. So when content editors are creating content of that specific type, they are not allowed to add anything else - the file browser restricts the list of files shown as options to only those matching the criteria for the use case. Not all bits are there at the moment to allow that, but that's something that we should be eventually providing a way to achieve via the admin UI I believe - no custom code required if possible. I envision this to be one of the features that would provide some sort of lightweight digital asset management capabilities to Backdrop core.

[docwilmot]

What I think we should do though is write proper field handlers so the Image Browser View doesnt depend on "Rewrite the output of this field". That always seems hacky to me.

[argiepiano]

What I think we should do though is write proper field handlers so the Image Browser View doesnt depend on "Rewrite the output of this field". That always seems hacky to me.

This sounds like the way to go.

[stpaultim]

I'd like to talk about this in a UX meeting sometime, because I think this is a complex enough issue that I'm not yet able to imagine all the implications for this, both pro and con. Also, I have a fuzzy idea of what the proposed benefits are, but I'm not sure if I'm understanding it correct.

[klonos]

This was discussed during the dev meeting today, 33:22 into the recording. Here: https://youtu.be/CTPd63wSpAg?t=2002

• The discussion started from Do not hard-code the "Select from Image Library" string in file_managed_file_browser_open() #6511, and then @jenlampton suggested that we should do what I am suggesting here before I even bring it up 🙂.
• There also seems to be consensus from @quicksketch that this is a good idea and something that we should have.
• The bit where we specify which browser (view display) should be used (in file/image field settings) should also be part of this feature here. @quicksketch made a good point that now that we have only a single such "browser" (the core-provided "image Gallery" view), it would be easier to manage the backwards compatibility aspect, whereas if we introduced the ability for file browser displays separately, and then people started creating and using those, it would be much more complicated to handle the upgrade path.
• Consider being presented with an option of which browser (display) to use if there are multiple of them
• Consider whether it would be better to have two separate views provided by core: one for files and one for image
• Consider whether it should be a single view instead, with 2 separate views displays: one for images, one for files. @jenlampton pointed out that this might complicate the UI (people will need to select 2 things: the view, and then which of the displays within that view)
• Consider what happens even now if someone disables or deletes the "image Gallery" view. So perhaps consider providing a way to "lock" these file browser displays.

[indigoxela]

I'd like to point to the now existing contrib project: https://backdropcms.org/project/file_library
It provides, what has been requested here (a file browser) - in a different way.