[UX] File types: Better UI for listing and selecting MIME types

[klonos]

We should explore the option of merging the "Media types" field and the "Available media types" fieldset into a single list of nested checkboxes (collapsed at the top-level MIME type). That way, we would reduce the length of this page (less scrolling -> better UX), and at the same time imrpove the UX even further, by allowing people to select MIME types, instead of having to copy-paste them into the "Media types" field.

There are a couple of 3rd party libraries that allow that, and there already exist Drupal modules for them:

https://www.drupal.org/project/nested_checkbox (uses http://jlbruno.github.io/jQuery-Tristate-Checkbox-plugin)

https://www.drupal.org/project/jstree (uses https://github.com/vakata/jstree | demos: https://www.jstree.com/demo)

https://www.drupal.org/project/bulk_select

https://github.com/uoziod/deep-checkbox (demo here: http://uoziod.github.io/deep-checkbox)

Screenshot of the document file type configuration page as it currently is, with the "Available media types" fieldset expanded:

[klonos]

Noting that https://www.drupal.org/project/checkall might be of help, and also that perhaps a CSS-only solution for expanding/collapsing groups of media types might be possible, with the method described here: https://iamkate.com/code/tree-views (thanks @albanycomputers for mentioning this in Zulip 😉 )

[avpaderno]

I like this. It makes more sense than entering values for which I am given a list of available values.

What happens, with the current code, when Media types contains a value not listed as available? Is it possible to enter a value that should be considered as "custom value"? (I am asking just to understand what needs to be changed in the actual code and which changes should be introduced.)

[klonos]

...Is it possible to enter a value that should be considered as "custom value"?

Good question @kiamlaluno! ...the list of media types and extensions is coming from file_default_mimetype_mapping() and it is currently hard-coded. However, there's file_mimetype_mapping() (which is the only place in core where file_default_mimetype_mapping() is used), and that function includes a backdrop_alter() call to give other modules the opportunity to alter the table that is returned by the default list.

file_default_mimetype_mapping() seemed silly to me for a couple of reasons:

1. We return 2 separate arrays - one for the MIME types, and one for the file extensions. I thought that it would be better to be returning a single, multidimensional array, in the form of media_type_registries -> media_types -> file_extensions, but that's better left for a separate issue (perhaps, perhaps not).
2. We are hard-coding the set of MIME types (now officially called "media types" - see https://www.iana.org/assignments/media-types/media-types.xhtml) and the respective extensions, when it seemed that we should instead be automatically compiling or grabbing those from the source of truth ...but then again, when I started going down the rabbit whole of finding a way to do that via native php functions or readily available 3rd party php libraries, I got lost 😵 ...IANA provides a list of all media types, but not their associated file extensions (there's one such list available here though (from apache.org) - but we'd need to parse it and generate a list - there's scripts that people have created for that!) ...native php functions are not reliable, nor do they work across all operating systems or hosting providers without installing additional PECL packages (which is not an option in many low-cost hosting providers) ...3rd party php libraries that require composer ...so many factors! ...there's heaps of articles about this matter and people attempting to find a reliable solution for years now, but I have found this article summarizing the "ordeal" the best (really worth the read if you don't wanna waste lots of time reading through comments on php.net and stackoverflow.com like I did 😓): ...so definitely a subject for a separate issue!

Anyway, good news is that I have started working on a couple of solutions on my local. Initially (as per the 2-year-old summary of mine here), I was looking for a tree-based checkbox solution, but it then seemed to me that instead of having the users go on a hunt of expanding/collapsing/ticking/unticking through dozens and dozens of available checkboxes of media types, we better use some sort of autocomplete.

...one of the PoCs I have on my local involves using a customized '#type' => 'options' form element (that one still needs lots of work), and the other involves a multi-value set of autocomplete fields, for which I'm pretty close to provide a PoC PR for soon(ish) ...here's a couple of screenshots from that as a teaser:

• the monstrous "Available media types" fieldset is gone from this form!
• the entire "Media types" text field is replaced by a series of autocomplete fields (the config still saves the media type, but you can search either by media type or file extension):
• the logic is smart enough to remove previously-entered media types from the list of autocomplete suggestions (notice how image/jpeg is not included in the suggestions when typing peg, since it is already added to the file type):
• if the user has entered an entire registry/wildcard of media types, the logic is smart enough to remove the rest of the individual media types that belong to the registry from the list of autocomplete suggestions (notice that there are no audio/... suggestions in the autocomplete, since audio/* is already added):

Pretty cool huh?! 😉

[avpaderno]

@klonos I would say, good work! It's better than having a long list of checkboxes to select.