Add download attribute for Media with a direct url to the Media file entity

Hi mpp,

Your patch works on D8.6.1 / Linkit 5.0-beta7. Thanks for that.

Next step if possible, add the title to file name in download attribute instead of download.

P.S. : Don't forget in the Readme : Check the option in Linkit URL converter option

Hi mpp,

Thanks for this new patch. I test it quickly and I give you a new feedback soon.

The patch was succeeding but the code was throwing an error because $settings['download'] was undefined when attempting to get the #default_value. This patch fixes that issue for me, in 8.6.2.

Looks good. I would like some more information about the "download" attribute but I can't find any.

Where can I read or see this?

Please take the module media_entity_download into account. It handles download of media more robust by creating a proxy URL for files. Major benefit: Media download links become predictable and don't change if a media source file gets replaced and therefore changes the file URL. Also access checks are in the make to honor publishing workflow for media entities (as well as private files permission checks).

Nice, thanks for the patch @mpp. Works well on our test environment.

Great work! Thanks for the patch.

Thanks for working on this. I thought I had everything correctly configured, however the download attribute seems to be populated with the file's media_field_data "name" value.

<a data-entity-substitution="media" data-entity-type="media" data-entity-uuid="fb415703-ba62-4256-aecb-61d64c8c4151" href="/media/17" download="demo txt" title="demo txt">/media/17</a>

The URI is: public://2019-06/demo.txt

We are requiring users to provide a name on upload and this doesn't always match the filename.

Is this working by design and we need to auto-populate/disable the name field with the filename for this to work?

I'd say that's a bug. The problem is that the logic for this is outside of the media plugin, because the substitution plugin doesn't have the ability to return that information, so it is hardcoded outside.

Two ideas:

1) Add a method specifically for Media that we can call there, so at least the logic is where it belongs, would still be hardcoded.

2) Introduce an Interface SubstitutionUrlAlter or something, with a method like $substitution->alterUrl($element) (a bit strange naming..).

Then alternative implementations could do something like that, we could even have the configuration on the substitution plugin where I'd say it belongs instead of the filter format (where you might need to configure it 3x for different text formats), it would even allow to have different profiles that add the attribute and others that don't.

we could even have the configuration on the substitution plugin where I'd say it belongs instead of the filter format

Yes, this sounds like the way to go..

@anon: Do you want to revert this or create a follow-up? Might be a bit weird if we move the settings around in a follow-up?

@Berdir: I can revert this later today. This fix is only in the dev branch anyway.

Reverted now.

Please add this patch to fix a notice.. it's filling up the recent log messages.

Rerolled #17 since it worked for our use case, but I'll keep the issue on "Needs work" since it obviously still has some issues.

If only I had made the patch correctly... sorry for the spam

I am under the impression that the latest patch #31 to fix the notice is already included in 6.x. Setting this issue to RTBC. Perhaps others can confirm this before closing this issue.

I would recommend the maintainer to close this issue if confirmed that the fix is included in 6.x. The failing patch does not need to be merged anymore.