Problem/Motivation

In the Media Browser a couple of suggestions:
* when adding bulk images, it's time-consuming to add Alternative text to each - could pre-fill with a version of the filename eg remove extension and hyphens, underscores
* when adding media [+Add] you have to select the Audio, Document, Image 'tab'. This can be forgotten so you can load images into Audio category etc. The incoming filenames could be checked for extension and rejected if wrong type.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jons created an issue. See original summary.

rang501’s picture

For bulk uploading - there is actually a feature to exactly for this: Bulk actions. https://project.pages.drupalcode.org/media_directories/features/bulk-act...
Turn it on and you can fill any field. This also supports translating, so you can bulk add translations.

Second point is unclear - is something broken there?

jons’s picture

thanks
I have been doing 'bulk upload' but did not know about the special feature! Maybe enable by default?

The second point is to try to stop people uploading mp3 files as Images

anybody’s picture

* when adding bulk images, it's time-consuming to add Alternative text to each - could pre-fill with a version of the filename eg remove extension and hyphens, underscores

I think that would also be an anipattern so it's good not to do that. File names as alt texts are not better then empty ;)

* when adding media [+Add] you have to select the Audio, Document, Image 'tab'. This can be forgotten so you can load images into Audio category etc. The incoming filenames could be checked for extension and rejected if wrong type.

@jons could you please check which file types your image media allows? Does it allow mp3?

If yes, that should not be possible and handled by the module, yes. If your image media type aka its file field is misconfigured, that should be fixed in your installation.

Maybe a test could be added here to ensure the file type validation works as expected - if not yet existing?

jons’s picture

Hi
If I'm in the Media Browser, I can drag-drop a jpg as an audio and a mp3 as an image
I cant see a way to set filetypes in that context

  • rang501 committed 5867cbbe on 3.0.x
    Issue #3613872: Validate uploads server-side in the browser upload...
rang501’s picture

Status: Active » Needs review

I agree with @anybody about the alt texts - this module should not try to autofill it. If you really need it, use media entity hooks to do this automatically, with your own rules and responsibility. The bulk actions are not for everyone, so I would keep it off by default. It is now documented under features.

The validation problem should be fixed now, it was missing. Only combined upload did the checking.

jons’s picture

👍
@rang501 Can you say which hook is best as most 'media entity' hooks are CRUD lifecycle ones which are downstream of your dialog, and you're using a REST protocol so hooking into the form is not possible. Better to add a js 'behavior' to modify the dialog fields 'onClick' ?

anybody’s picture

Version: 3.0.0-beta1 » 3.0.x-dev

@rang501 commit shows improvements based on the file type. Especially for file types that are not allowed in any media type.

Is the case of uploading a file type that is allowed in multiple media types also already covered?
For example an image could be allowed as image media and document media in some cases, based on the context. In that case the user would need to make a choice?

  • rang501 committed 60f1cc06 on 3.0.x
    Issue #3613872: Add an event to pre-fill upload form metadata such as...
rang501’s picture

@jons
I think what you need is something different - I was thinking entity hooks, but the upload does not touch them until they are saved, so it may not fit in you use case - you probably want to prefill after upload and show it to the user before saving. This was not possible before, so I added general event to alter metadata. This allows others to set their own values as well - i.e use exif data

To get started, check the documentation:
https://project.pages.drupalcode.org/media_directories/extending/#pre-fi...

@anybody

I'll give a short summary, how the upload works with the module.
The browser has two methods to upload media.

First is similar to how core media library does this - user needs to select media type to upload.

The second way is combined upload. This method allows to combine multiple entity types into single upload form and select any supported (has file upload field) media type - backend tries to match the file type with combined media type. The issue here is that if one file type is allowed more than one media type - media type detection may select the first matching type it encounters. For this it is possible to not include conflicting media type in settings. In conclusion this is to make file uploading more comfortable to bulk upload many different file types at the same time - backend figures out what goes where.

The combined upload was more tested on my end and the first method was not tested that well. The issue was with the first method, which did not reject invalid files. The combined upload does not handle conflicts, it is up to site admin to configure it - most of the time this means excluding the conflicting media type from combined upload.

anybody’s picture

Thanks @rang501 that sounds great and thank you for the verification. The combined upload is GREAT!

If I'm getting you right, there is one "minor quirks" left: If a file type matches multiple media types, there is no user selection yet to select which media type to use, right? Instead the system picks the first one.
You described a configuration workaround, which I think might solve many cases but is still not the ideal solution.

So my question is, if there might be an even more flexible solution that resolves this quirks finally, letting the user decide the media type in this case? I guess the problem is, that the file is already uploaded in a certain media type at this point?

So in this conflict it would either need an intermediate step or an option to not handle these conflicting files at all and ask the user to upload it to one of the manually selected media types?

rang501’s picture

@anybody
I would assume most sites have default media types or types which have no colliding file types. If some site will have such collision, it is possible to include the type most commonly used into combined upload and keep the other one separate. This would allow user to decide which type to use.
Separate screen to select media type for file is possible, but I think it could make the flow a bit confusing.

Before deciding this I think someone should provide real life examples. If I remember correctly, there have been no previous issues raised on this. But I would implement a check on configuration screen to notify collision if detected. Maybe even improving the upload field on combined upload to show which types are there.

anybody’s picture

Thanks @rang501 I totally agree! And should I run into this issue in some project I'll report it here.

Having a check to let the user know in case of the collision would definitely be helpful, I think.

  • rang501 committed d393d219 on 3.0.x
    Issue #3613872: Warn about combined upload media type collisions on the...

  • rang501 committed 8b85888b on 3.0.x
    Issue #3613872: Let editors pick the media type per file when combined...
rang501’s picture

I was thinking about it. There may be some valid reasons why for example an image would be a document for example photographed documents.
So I implemented the feature and updated the document:
https://project.pages.drupalcode.org/media_directories/features/uploadin...

rang501’s picture

Status: Needs review » Fixed

This looks to be stable enough for the release.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.