[META] File management (media browser, fields on files etc)

[mikemccaffrey]

We may want to consider expanding the functionality supported by core for file entities. Particularly, it would be good to provide the same functionality as the File Entity contrib module for drupal: https://www.drupal.org/project/file_entity

Things that would be good to have:

• [ ] #1380 Upload multiple files at once
• Reusing files via media browser
  • [ ] #2718 Create another interface (view) for listing manage uploaded files for internal system use named "Media Library Selector" or similar. Its goal is to provide a way to list files and allow the user to select one for use by the calling form element/mechanism.
  • [ ] #2720 Create a new form which wraps two of the above items together:
    • Upload new file
    • Choose an item from the Media Library Selector view
  • [ ] #1307 Create a new file field widget that implements the above new form so that the user can easily upload a new managed file, or select an existing one.
  • [ ] #2719 Modify the CKEditor image dialog to use the new form when adding a new image to the content
• [ ] #2721 Create a new dynamic file field formatter that attempts to handle output of any file appropriately for its file/mime type.
• [ ] #4007 alt + title fields

Things that are done:

• [x] Files that are proper entities
• [x] #2375 An interface to list and manage uploaded files
• [x] #2796 Add the ability to edit an existing managed file
• [x] #2633 A way to upload a file outside of file fields or Rich-Text editor uploads
• [x] #2632 Core fieldable file entity bundles
  • [x] Determine core file entity bundles (image, document, other?)
  • [x] Make bundles fieldable

Related Issues around garbage collection:

• [ ] #2896 Side-wide settings for garbage collection
• [ ] #2897 File entity garbage collection settings
• [ ] #2898 Admin interface for manual garbage collection
• [ ] #2899 Confirmation dialog for orphaned files

[klonos]

Yeah, I recently read through a D8 issue for a feature that got implemented (can't remember the exact issue right now) and came across the separation/terminology of file and file_managed or something. So in D8 they either support managed files, or at least they have laid the foundation for it.

Not sure how/if this fits in #378 ?

[klonos]

...not entirely sure about this, but I think that there was some work done:

What's Coming in Drupal 8

The initial architecture simplifies media handling and is centered around a new "media item" entity type who's bundles can be fielded with a variety of field types to provide the actual media resources.

In short the file entity module will be no longer necessary for media handling solutions under this model and media browsers, widgets and so on will build on top of this lightweight entity. We are taking advantage of entity reference being provided by core in D8.

So this might be based on or related to Entity Reference (for which we have #1301) and then implementing a solution in contrib (Media entity & Entity Browser/File Entity Browser perhaps??) before merging it in core D8 sometime in a future 8.x.

Anyone that has been following the D8 Media Initiative please shed some light here.

In general, it would be great if we had our own media/file management in core plan.

[klonos]

...may I add Entity Type Browser to the list of related contrib modules. I've filed #1449 for it.

[ghost]

Trying to port the scald project to backdrop, I was quickly stuck by the heavy CTools dependency, plus Scald "atoms" are not "real" entities (in the drupal8 (sorry, backdrop) sense); I realized that after all we do not need specific entity type for media, and decided to use nodes... This is perfectly compatible with diagram above, and, more importantly, it works ! So we get "Back" to the drupal6 paradigm of the image module, image_attach, img_assist, image_gallery, etc... The scald library module makes a good entity browser (actually a node browser) The atom reference module makes a good entity reference (actually node reference) And, most important, we have a superb CKEditor integration...

As of today, I have a working solution, which works perfectly (that is, as well or better than drupal) for the end users, both visitors and contributors. From the site admin point of vue, that's another story : fields and content types must be configured manually, following simple yet strict rules : for example, the scald_image defines an "image" type, so you must define a content type with machine name "image", and, at least, an image field named "field_image", and so on for the various providers - ported as of today : image, audio, video, file, iframe, and gallery. A file is not needed, just a field. The site builder must also deal with the "manage display" of the media, versus the "manage display" of the embedding and/or referencing entity. It's no more no less complicated than with any other media solution, but here everything is node, and shares the same configurarion page... I personnally prefer this solution (of course...), but it requires a certain level of abstraction, which is perhaps not very coherent with Backdrop marketing material... Now is there any other foreseeable solution better on this point ? The project today is far for a contrib revue level, it's not even "stable", but if anyone with a reasonable knowledge of scald is interested, please let me know...

[ghost]

I managed to solve the installation/configuration issues, and have now an operational platform for media management.

It's at https://github.com/gifad/backdrop-mediakit

This is really work in progress, large parts of the code need a complete refactoring. However, it works, and there is even a demo site, at :

http://p1347.phpnet.org/backdrop/l/3rgz8UIEd0Vd/

The account provided by this autologin link has a pretty complete set of administrative permissions, so you can get an idea of the underlying architecture; you can even play with various settings, but please try to leave the site as you found it - if you can't, drop a message in the “contact page”...

enjoy !

[quicksketch]

However, it works, and there is even a demo site, at :

Wow, you have a full port of Scald! Impressive!! We'd still love to have some of your work in the contrib group, though I understand time limitations. In any case, it's still great to see the work you're doing. :smile:

Also, thanks @mikemccaffrey for opening this issue. I thought we already had an issue for this, but I guess not.

Particularly, it would be good to provide the same functionality as the File Entity contrib module for drupal

Absolutely agreed. I'd love to move in the functionality for managing files. e.g. Create a Admin > Content > Files listing page and make a URL for each file to manage any fields it may have or see where the file has been used.

[quicksketch]

Let's add this a wishlist item for the next release (1.4.0). I'd love to see this sooner rather than later.

[docwilmot]

@gifad if you push a PR, we'd get a sandbox to see how this works now.

[ghost]

Push a PR where ? My scald "port" (actually a fork…) is still in an alpha state, and I can't imagine how could its components fit in backdrop core — a huge refactoring is still to be done, just to put it in a state acceptable for a contrib project. The task is similar as taking the Drupal8 Media Entity project, and rebuilding the Drupal6 image module.

Anyway, if you need a sandbox, the links above are still valid, and the demo site and the github repository are synced.

Edit : I have to add a note : this project approach is radically opposite of "Fieldable file types" : it's based on the approach that "Media is Content" — an Image is not a file, not even a field, but a node, with of course an hidden image field, but a visible extra_field named representation - a youtube video is hosted in a textfield, and represented with an iframe. and, yes, I consider node as the machine_name of Content —with scald, it's hypercontent, hyper as in hypertext at least I try…

[jenlampton]

related https://github.com/backdrop/backdrop-issues/issues/2070

[jenlampton]

Adding this to 1.6 milestone for now. We'll see if it sticks :)

[jenlampton]

Removing the 1.6.0 milestone since this whole meta won't get in to 1.6, added the milestone to https://github.com/backdrop/backdrop-issues/issues/2375 instead.

[jenlampton]

There are a lot of issues in this meta, and some of them may get into 1.8, but not all will. I'm going to bump the milestone from the meta to 1.9, but keep the 1.8 milestones on the sub-issues that are still likely to get in.

[klonos]

...just created #3136 Related??