Drag and drop of media files not allowed on paid simple sites

gikaragia commented 3 months ago

Quick summary

Trying to drag and drop media files to the editor, it fails.

Steps to reproduce

Create a site with the Personal or Premium plans
Open the page to create a new post
Try to drag&drop an audio file (e.g. .mp3 or .wav)

What you expected to happen

The audio file to be uploaded and the audio blog to be created normally

What actually happened

The audio file is not uploaded and a message of 'Sorry, you are not allowed to upload this file type.'

Impact

All

Available workarounds?

Yes, difficult to implement

If the above answer is "Yes...", outline the workaround.

The user can still go to the media library, upload the file, and then select it in the audio block.

Platform (Simple and/or Atomic)

Simple

Logs or notes

I did some debugging and it seems that the error is caused by the function wpcom_site_has_upgraded_upload_filetypes (and get_current_blog_id) retrieving the wrong blog_id. It retrieves the blog_id of the API and not the blog_id that the user is currently modifying.

Subsequent requests and calls to the same method retrieve the correct blog_id which hints that the method in that case is either called too early or the blog_id is not correctly set.

jartes commented 3 months ago

📌 REPRODUCTION RESULTS

Tested on Simple – Replicated
Tested on Atomic – Replicated

📌 FINDINGS/SCREENSHOTS/VIDEO

I can replicate this unproxied, and on Atomic sites.
While it works for mp3 files, it doesn't work for wav and ogg files.

https://github.com/user-attachments/assets/3b4a5510-b36d-49c7-888f-af9d4bd081b5

📌 ACTIONS

Triaged

agrullon95 commented 3 months ago

Im not able to replicate this on a simple site on a Personal plan. Im able to drag and drop my mp3/wav file.

gikaragia commented 3 months ago

I tried this again and it works for me now too. It was happening consistently before. I'll try again tomorrow to see if I can reproduce it and let you know of the results.

gikaragia commented 3 months ago

Gave it another go and now it happens again: php

Here is the file that I am trying to upload: https://tinyurl.com/24tkan96

And the blog id: 220057576

DustyReagan commented 3 months ago

I can consistently reproduce this for WAV files on Firefox, but Chrome works fine for me. @gikaragia, could you please check if you're experiencing the same behavior?

Imran92 commented 3 months ago

I also couldn't reproduce it on chrome in a personal plan

gikaragia commented 3 months ago

Indeed @DustyReagan this is currently only happening in Firefox and with .wav files (although when I raised I remember it happening with other file types too). Sorry, didn't cross my mind to test with a different browser.

DustyReagan commented 3 months ago

Thanks, @Imran92 and @gikaragia! I also see this issue on Atomic and, more significantly, Pressable sites in the core (no Calypso). When I try to upload a .wav file, I see a console error Security Error: Content at [redacted]. may not load data from blob:[redacted]. I've tried reducing my Firefox security settings but still can't get the upload to work. I'm guessing this has something to do with uploading a blob and maybe Content Security Policy settings. I think this may be a Gutenberg issue. 🤔

Imran92 commented 3 months ago

I've looked into this issue for a bit. I was able to reproduce it even locally and without the Gutenberg plugin.

Looks like it happens only on Firefox.

Initially I thought it was a Gutenberg issue, but upon further digging, I found that WAV format has had these issues with Firefox from way back, It's not related to Wordpress or GB

Here are some instances -

https://bugzilla.mozilla.org/show_bug.cgi?id=1247826

https://www.reddit.com/r/firefox/comments/1dfnmk1/firefox_wont_play_wav_files_directly_in_the/

https://stackoverflow.com/questions/56128653/firefox-cant-decode-wav-audio-format

Imran92 commented 3 months ago

I think I've found the reason and the fix.

It involves a weird behavior of Firefox. When we upload the wav file @gikaragia gave us here, Chrome and all other browsers identify the mimetype of the file to be audio/wav, but Firefox, identifies the mimetype as audio/x-wav.

WordPress core has a default (extensible) set of mime-type that it allows uploading. You can find them here https://github.com/WordPress/wordpress-develop/blob/3b1e57752d5dd737477873b6797e3f8209aec078/src/wp-includes/functions.php#L3392-L3513 . You’ll notice that there is the audio/wav mime-type there, but not audio/x-wav. So when Gutenberg tries to check the mimetype of the file in Firefox here https://github.com/WordPress/gutenberg/blob/5773ae60ca33bda03f2a35e6707d961b8db3af18/packages/media-utils/src/utils/upload-media.js#L91-L118, it sees that the mime-type (audio/x-wav) isn’t one of the allowed ones. So it throws an error.

So, I think the proper fix will be to add the audio/x-wav in the wp-core function. I'll create a PR to add it there.

Also, an workaround will be using the mime_types filter. For example, as POC, you can try adding the following snippet and your wav file upload should start working as expected on Firefox

add_filter( 'mime_types', function( $mime_types ) {
    $mime_types['wavx'] = 'audio/x-wav';

    return $mime_types;
} );

miksansegundo commented 2 months ago

I tested the fix and works nicely. Nice find!

The fix is just a small configuration change on the mime file types supported in WordPress core. @annezazu, maybe you can help coordinate with core folks to get it merged?