This module will not alter the path of the uploaded media.
You'll need to use another module, see instructions here 📌 Map Media Directories to physical directories Active
Fixed in the 2.2.x branch.
Fixed in 🐛 Respecting file validator API Active
ytsurk → created an issue. See original summary → .
Thank you for reporting the issue. I'm having a look at it now.
Thank you for the error report and fix.
Core media has 24, so I suggest we take that.
An upgrade path will affect all that installed prior 2.2.2-beta4 (February 2024).
Does it make sense to do it for 2.2.0?
2.2.0-alpha1 released.
I tested a fresh install on D11, but not yet in every detail.
Thank you for your contributions, i'll want to make some extended tests and then will release 2.3.0-alpha1.
Thank you for your input, seems to make sense.
At first sight I thought that this is a pretty slim plugin definition. We should add some comment, to explain how to add such a derived AddForm.
Seems entity browser related, I don't get where you set this config?
Also only one site seems affected, right?
When you have that javascript error mentioned here: CKEditorError: plugincollection-soft-required {"missingPlugin":"LinkEditing","requiredBy":"EntityEmbedLinkUi"}
then enable the link Module and add a the link plugin to the CKEditor's toolbar,
see
🐛
CKEditor 5 plugin only works when the "Link" plugin is enabled
Needs review
entity_embed is not yet ready (waiting for embed) - #3430164 - this is a hard dependency for our D11 compatibility.
Further I guess we make another minor release targeting D10 and D11, like we did with D10 compatibly.
Hi Sariga,
we appreciate your work on 📌 Drupal 11 compatibility Active and are not looking for a co-maintainer currently.
But if you keep steady contributing, we can talk about.
We're doing the same thing here three times, can't this be en-capsuled in a helper function?
Thank you for reporting this issue. I'll will have a look at this soonish.
Will be fixed here 📌 Drupal 11 compatibility Active
Thank you two for your work
Thank you for your report.
I also have sometimes this behavior :(
What admin-theme are you using?
We support image cropping and other image field widgets.
What is your problem?
If the corresponding field has crop defined, you'll be able to adjust the crop on the Add/Edit dialog of this module.
Would also love to get some darkcheese.
Yes - you can limit the allowed media types via using a media entity reference's field setting.
Try the combined upload for having only one upload form w/o media type selection, you can enable it here: /admin/config/media/media_directories - this will also affect the media browsers main page (/admin/content/browser)
Yes - maybe the nested array is the problem.
You can safely upgrade to D10, this is just a warning and the module will work as expected.
Hi Niklas, thank you for reporting this issue.
When do you experience this behavior? Is that on the general media overview, or when you are in a node, working on content (using a field or CKEditor)?
Thank you for this contribution, and, yes it's a common use-case to select multiple medias.
We already have support ctrl + click to select several medias one by one. So this seems like a good usability enhancement to me.
Hi, your profile does a bit look like credit hunting.
Anyway, thank you for your contribution. I remember (also visiting my comments around your changes) that this what not possilbe 2 or 3 years ago.
How did you test this?
Good - it's in there.
Variable should not be used inside hyphens ..
Used wrong issue number in patch filename.
Here a patch.
Ah - and sorry for missing your username in the commit msg :(
Too many non-smiling similes here
Thank you for your contribution.
Sadly, I just saw this issue after the beta4 release :(
Looks good and in-line with AddMediaFormBase. Also my tests were fine.
Thank you for your contribution!
We go with a fixed version here, as this ensures stability and tested versions.
I'm using the module's version 2.0.4 with this MR's patch (https://git.drupalcode.org/project/layout_paragraphs/-/merge_requests/12...) for symmetric paragraph translation.
This module forces you to use go with asymmetric translation, which is not official supported (nor recommended) by the paragraphs module itself.
If you can explain the incompatibility issues you have, we can try to guide you?
What are your opinions on the new field-widget.
An update hook for existing installations can break individual configuration.
New installations then shall use it, so we would need to update the documentation?
Are we then having two form modes? Still the media_library one for our overview page and via CKEditor embed?
Do you somehow alter jsTree's menu_item's?
I'm not aware of a check this module does regarding a directories emptiness, our code we will always add a "Delete" context menu entry,
see here https://git.drupalcode.org/project/media_directories/-/blob/2.1.x/module...
Are you using any patches from other issues or use custom code? You would need to intercept the delete command and refresh the context menu accordingly ..
Thank you for this solid contribution.
Change makes absolute sense to me, interfaces shall be used to get back the preview always, and the thumbnail image style (100x100) can be replace with the media_library (200x200) one, both will be in place due to our dependencies.
From D11, also 🐛 Media Library image style shouldn't be able to be deleted through the UI. Fixed
Thank you for further information, Skrudge.
So I try harder to reproduce ...
I cannot reproduce this on the 2.1.x branch.
Sadly we do not support anymore the 2.0.x branch, please try updating to 2.1.x-betaY.
A more descriptive way of your problem would also help in reproducing it.
What means allow? What do you see when you right click the folder after deleting all containing medias?
What version of Drupal and our module are you using?
I want to check how core media handles this case. As I already committed the changes to the -dev branch we need to hurry up here ...
Yeah - seems like a misconfiguration or a incomplete install.
What Drupal version do you use? Please update to our 2.1.x branch, we do no longer actively support the 2.0.x branch.
Drupal 9 is end of life - PSA-2023-11-01 →
Thank you rang501, but where are these changes?
Good point - I really liked the fact of having three rows w/o scrolling :D
Why not make a warning on the status page, when you can upload more files then we display, with a recommendation to change the views pager size manually?
Thank you for filing this issue. Your patch looks good and works.
We use now the newly proposed hook.
I added now the full pager (with 18 items so we get 3 rows on desktops) and the sort (by changed, ascending).
I can confirm this now works. Thanks rang501.
I have the same opinion that we keep our dedicated column.
So, when we decide to offer a migration path, what shall exactly happen?
We let the user choose the existing field and take it's first value (a media shall only live in one folder), and copy it over.
At the end of the migration that field should be deleted, as we will not keep it in sync.
Thinking more about this, I agree that this edge case shall be handled by the user itself.
Thus closing this issue.
Thank you for reporting this issue kevinb623.
I don't get the exact use case. Did you change the vocabulary? Was this on installation?
It seems that we are incompatible with the default taxonomy reference field, but using a custom field.
Unsure if we shall offer a migration path, or change our custom field?
I would not introduce an update here.
This is for new installations, already running ones will have made their customization, eventually ;)
Yeah - this was 2021 with the mindset that we have directories (always showing everything like the file manager of your favorite OS),
and if I would have 100K of medias, I would have a ton of folders and not having all medias shown in root.
But no doubt, we will now add a pagination out of the box to reduce support in this direction.
The question remains, shall it be:
- Regular Drupal pagination
- Custom Pager
- Another module dependency
Whereas I vote for the custom pager.
And we should change sorting to newest first.
Good point with the sort, did not think about, we should definitively to change to newest first, or even expose the sort with options alphabetical/newest first/oldest first.
As I said, I would not go with an entityquery and stay with views as it offers a lot of customization just via the UI (no code).
But still, if you want, check the difference, we can introduce another setting - entityquery/regular view ;)
Whereas a pager is needed anyway IMO, as making sense, and aligns with core.
This seems to be a configuration issue of the file field of your media entity.
The error message in the screenshot really means the file could not be transferred - maybe also check you PHP settings.
For me in firefox the reload does still happen when I press enter in the search field ("filter").
Thank you for the input.
Let's support this theme too. And others - We had once the idea of letting you add any library you want ✨ Shall we allow to add a custom library Active , would be nice to have a select with some theme's in it, maybe even pres elected, beside a textbox letting you give any library.
We actually did not want to remove support for seven already now.
Thank you all for your inputs, and yes, we definitely should address this now.
Demand seems here, and we should have larger installations in mind.
Why not just introduce pagination, using the current admin themes pagination at the end of the scroll-able media area ?
Although, I don't like the idea of having another dependency (
infinite scroll →
, which I like a lot) - especially for something we can do our self with minimal effort.
Thinking about that, an endless scroll would be a great fit IMO.
Why not implement our own views pagination, just having a load more button maybe having one or two settings like pagesize (bonus:auto-scroll when in viewport setting).
If we also could support the regular pager, all are still free to choose and we have the problem of directories (or ROOT) loading slow eliminated our self.
The idea of using direct entity queries would be an option for me, if loading times would increase dramatically ..
Anyway, who really needs to scroll thousands of medias, I always use the search. I can only imagine a special case, where I search for a thumbnail.
I also decided (again) to go with a custom solution .. using data-src, the oembed thumbnail and the no-cookie domain.
(Not using a consent banner, so the cookies module seemed to heavy for me, although I did not tried)
But still I would welcome the no-cookie domain and the vimeo setting toggle (aka more privacy) for core's external video media type!
What a story - thank you all for the hard and intense work!
Now this survives an update for me :D
Thank you for reporting this problem, we'll have a look at it soonish.
Sorry - I just released beta3.
I just saw https://github.com/vakata/jstree/tree/8c1bcc87771f5be0b70cd49d6a7888707e... which can be set here: https://www.jstree.com/api/#/?f=$.jstree.defaults.core.themes.name
Definitely the way to go IMO.
Looks like we're not compatible with 9.4, thus the information on the project page for 2.1.x will be changed.
We only support Drupal 9.5, see https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/medi...
Sorry ..
Sorry - review welcome, especially the update hook (meaning running it on another -dev instance then mine).
Sorry for having this so long silently assigned to me, doing nothing, but here we go.
I added the update hook for the config schema change.
Also renamed stuff a bit and added the config options to a separate fieldset.
I needed the patch from 🐛 PHP Fatal error: Uncaught TypeError: fclose(): Argument #1 ($stream) must be of type resource, bool given in /var/www/html/sites/all/modules/contrib/httprl/httprl.module:1885 Needs work and #4 from here to get it running.
I also needed the patch #4 from 🐛 PHP Fatal error: Uncaught TypeError: fclose(): Argument #1 ($stream) must be of type resource, bool given in /var/www/html/sites/all/modules/contrib/httprl/httprl.module:1885 Needs work to get it working again.
📌 Fix INI directive track_errors PHP 8.0 compatibility errors Needs review