Closed (fixed)
Project:
Media Directories
Version:
3.0.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
29 Jul 2026 at 15:13 UTC
Updated:
5 Sep 2026 at 20:25 UTC
Jump to comment: Most recent
Comments
Comment #2
rang501 commentedFor 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?
Comment #3
jons commentedthanks
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
Comment #4
anybodyI 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 ;)
@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?
Comment #5
jons commentedHi
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
Comment #7
rang501 commentedI 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.
Comment #8
jons commented👍
@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' ?
Comment #9
anybody@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?
Comment #11
rang501 commented@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.
Comment #12
anybodyThanks @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?
Comment #13
rang501 commented@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.
Comment #14
anybodyThanks @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.
Comment #17
rang501 commentedI 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...
Comment #18
rang501 commentedThis looks to be stable enough for the release.