Allow file uploads using drag and drop & add placeholder

[jasmussen]

WordPress supports a number of image, audio and video filetypes. We have media placeholders for each of those, and you can drag and drop them to upload.

WordPress also supports a number of filetypes that aren't media, such as pdf, doc, and others. See full list here: https://codex.wordpress.org/Uploading_Files

You should be allowed to upload and insert these files using drag and drop from the desktop. For example if you drag and drop Schedule.pdf into the editor, you should get a file block, like this:

From that, you could copy the link and paste it over text if you like, to create a normal link:

There would also be a placeholder block for files:

[mrjarbenne]

Glad this is on the radar. The lack of a "Files" block resulted a few moments of unsuccessfully attempting to insert a file. At first I thought perhaps the "Images" block might play double-duty as a general media upload, but it doesn't allow alternate formats. I eventually opened the Media Library in a separate window to upload a PDF, copied the URL, and then added it as a hyperlink back in the post. This was very cumbersome. If there is an alternate way to do this currently, it wasn't obvious.

[mirka]

I will be working on implementing this feature. Here is what I plan to do:

• A file block seems useful for all filetypes — including images, audio, and video — for when the file is intended primarily for download and not for embedding. So we probably want the file block placeholder to also accept image/audio/video, and for the blocks to be transformable.

  If a file is drag & dropped to a non-placeholder context and a filetype-specific block for it exists, it should take precedence over the generic file block.

• We will allow users to enter an arbitrary (internal or external) URL as the source of the file, like for the video and audio blocks. This seems good for consistency.

• Since the set of acceptable filetypes is dependent on the environment, we cannot always rely on the set listed in the docs. I feel like we should be permissive about the types of files the user tries to upload, but then instead have utils/mediaupload.js be responsible for notifying any errors based on the API response if the upload fails due to restrictions. Then we’ll show visual feedback to the user that the file can’t be uploaded, and why (restricted filetype, exceeds max filesize, etc.).

  Doing it this way would fix some issues with the other media blocks, too. For example, the image block looks like it’s accepting .svg files, even though it’s silently failing since SVGs are restricted from being uploaded to the Media Library.

Let me know if there are any concerns or suggestions about this approach.

[jasmussen]

That approach sounds great, thank you @mirka!

[nb]

@mirka, the plan looks good. The idea of allowing the user to upload anything and then let them transform the block into a specific one is especially powerful.

If the user specifics a URL, will we download the file or link to it/embed using the external URL?

Do you think we can somehow communicate with Gutenberg that are the allowed filetypes to avoid errors after upload (I would have to upload a 2GB log file to be rejected)? Can we do it? Are there any downsides?

[mirka]

I‘m thinking of making the text link part a normal link, and the download button an HTML5 download link. The download attribute will be ignored in IE, iOS Safari, and for cross-origin links. In those cases they will just act as a normal links, but I think it’s a good balance between code simplicity and convenience.

@nb:

If the user specifics a URL, will we download the file or link to it/embed using the external URL?

For now I‘m not going to sideload specified URLs, to keep the behavior consistent with audio/video blocks. This means that:

• File blocks with external audio/video URLs will be transformable into audio/video embed blocks, because the current implementation of those blocks accept external URLs as sources (without sideloading).
• File blocks with external image URLs will not be transformable into image blocks, because images for image blocks need to be uploaded to the Media Library (at least in the current implementation).

Do you think we can somehow communicate with Gutenberg that are the allowed filetypes to avoid errors after upload (I would have to upload a 2GB log file to be rejected)? Can we do it? Are there any downsides?

Good point. I looked into this and found that a pre-check and error-messaging enhancement is in the works (#4203). I think we could add a mime type check in there using get_allowed_mime_types(). I’ll post a separate issue for that.

As for downsides... I feel like it would be much easier for everyone if the REST API in Core could handle it better, like check the headers for Content-Type and Content-Length first and return an error without waiting for the binary transfer to complete. But I guess life is not that easy!