Add a URL field for File blocks

[shaunandrews]

The Audio and Video blocks allow using a URL for the media. However, the File and Image blocks don't. I'm not sure why its like this, but I feel like the URL option should be available to all of these blocks.

Here's a comparison of the four blocks:

[didipaterno]

I agree with this. I had a difficult time adding photos with URL, so I reverted back to the classic editor

[mtias]

Image has this already (in 4.1).

[sarahmonster]

💯

See also: #8409!

[designsimply]

I noticed the file block uses the download attribute for <a> links and that the download attribute only works for same-origin URLs. Noting this because if a URL were to be added as an option for a file block it may need to behave differently for HTML5 and become just a link without the explicit download option for that case. (You may already know this! Apologies if it's obvious or repetitive. 🙂)

[talldan]

Adding the ability to insert from URL to the file block would create quite a lot of overlap between it and the button block.

Not necessarily a bad thing, but was wondering what use cases could be achieved with a url in the file block compared to a url in the button block?

[gziolo]

@draganescu, aren't you working on some media blocks unification? Is it part of the scope of your work?

[talldan]

#15515 should close this.

[druxstr]

#15515 evolved to #19174, which was merged to 7.3 without adding a URL field for File blocks

@talldan a use case could be :

I want to add a file for my visitors to download, but the file is on another website

The File block is relevant, as the intended action is file related. The File block displays the file name and a "Download" button : this is more helpful than a Button block.

Other use case :

I want to add 2 files for my visitors to download. The 1st file is stored in my media library : I can use the File block. The 2d file is on another website : I can't use the File block.

Here the user is doing the same action, but the File block limitations are getting in the way.

[talldan]

A restriction would be that the 'Download' button wouldn't be possible for cross origin resources (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a):

download only works for same-origin URLs, or the blob: and data: schemes.

The way this would work is that the browser would still offer to download files that it can't handle, but for other files (like images, videos) that the browser can display, the file block would just act like a link.

The file block could still show the link and the Copy URL button in this case. I wonder whether also displaying some indication that the link is from another resource would be a good idea.

[druxstr]

Any update on this?

[shaunandrews]

Using the URL field could lead to a scenario where the "download" button doesn't actually download anything due to the same-origin requirements discussed above.

I think we could incorporate the URL field for the File block, but it would require adding the linked resource to the site's Media Library — and I see that as an entirely different issue to work out.

With that in mind, I'm going to close this issue. If you disagree, by all means comment or reopen for discussion.

[JosVelasco]

Using the URL field could lead to a scenario where the "download" button doesn't actually download anything due to the same-origin requirements discussed above.

I think we could incorporate the URL field for the File block, but it would require adding the linked resource to the site's Media Library — and I see that as an entirely different issue to work out.

With that in mind, I'm going to close this issue. If you disagree, by all means comment or reopen for discussion.

I want to add a PDF file for a magazine. This PDF is not hosted on the same server, but in a CDN.
Perhaps checking for the URL extension would make sure the link actually downloads something.