Media player not working with 302 redirects

[hlashbrooke]

When calling the audio player using wp_audio_shortcode( array( 'src' => '/path/to/file' ) ); and the path in question is a 302 redirect to an actual audio file, the audio player cannot find or play the file.

A prime example of this is with Microsoft's OneDrive - a public link to a file stored with them looks like this: https://onedrive.live.com/download?resid=###. Going to that URL ends up in a 302 redirect to the actual file. While OneDrive may not be the best way to store and share media files, it is still a valid use case. Plus, this will affect any file storage where the file is accessed via a 302 redirect.

There are alternative audio players that can handle 302 redirected files, so it's not impossible to work around the issue.

For reference, this came up in a support ticket for one of my plugins - details here: ​https://wordpress.org/support/topic/direct-link-to-onedrive.

[wonderboymusic]

This would probably have to be fixed here: ​https://github.com/johndyer/mediaelement

[desrosj]

I did some testing on this today. Here's what I found.

In the Classic Editor, the behavior is as follows:

• Clicking "Add Media" and selecting "Insert from URL" leads to the file being embedded as an HTML link.
• Inserting a [audio fileurl="urlthatisaredirect"] leads to a shortcode preview that just hangs in the loading state.

In the block editor, the behavior is as follows:

• Inserting an audio block and clicking "Insert from URL" successfully loads the audio player with the correct track length displayed in the player. However, the audio cannot be previewed as none of the controls work. This seems to happen regardless of whether the audio block is added using a URL or by selecting an audio file in the media library. Even after the page is reloaded, I still cannot preview an audio block. Viewing the page on the front-end, the players are all usable and correctly process the 302 link.

I'm wondering if this has to do with the function calling wp_check_filetype(), which attempts to match a file type from a file name. Because the URL does not include an extension, the function is unable to accomplish that and wp_audio_shortcode() is returning without any generated HTML to display an embed.

I have not had a chance to look into how the block editor implementation is different, but the code responsible for generating the audio block preview is doing something different. I'm going to move this back to the Media component as it seems something is going on with the shortcode or media related code and not the MediaElement.js code.

[gaisma22]

Reproduction Report

Environment

• WordPress: 7.0-beta6-62085-src
• PHP: 8.3.30
• Server: nginx/1.29.7
• Database: MySQL 8.4.8
• Browser: Brave
• OS: Ubuntu
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None
• Plugins: None (first test), Classic Editor 1.6.7 (second test)

Steps taken

1. Created a new page and added an Audio block.
2. Clicked Insert from URL and pasted a OneDrive public share URL (302 redirect to an audio file).
3. Audio player appeared but showed 0:00 / 0:00 - no duration, controls do nothing.
4. Published the page and checked the frontend. Same result.
5. Reset environment. Activated Classic Editor.
6. Created a new page. Clicked Add Media > Insert from URL with the same OneDrive URL. Rendered as a plain HTML link, no player.
7. Switched to Text/Code view and inserted: [audio src="onedrive-url"] Frontend showed the URL as a plain link, no player.

🐞 Bug is occurring

Expected behavior

A OneDrive public share URL (302 redirect) should load and play correctly in the WordPress audio player in both the block editor and Classic Editor.

Additional Notes

1. Right-clicking the audio block and opening the URL directly in a new tab confirms the OneDrive URL is valid and accessible - the player just can't resolve the redirect.
2. Behavior consistent with comment #2 by @desrosj. Bug still reproduces on 7.0-beta6.

Screenshots/Screencast with results

Block Editor:

Classic Editor:

[gaisma22]

Removing needs-testing and dev-feedback. Adding needs-patch.
Bug confirmed reproducing on WordPress 7.0-beta6 in both the block editor and Classic Editor.

Summary of my changes:

• Updated wp_audio_shortcode() and wp_video_shortcode() to only return a plain link when the URL does not have any extension.
• Made the type attribute on <source> tags conditional i.e. when the MIME type cannot be determined (redirect URLs), the type attribute is omitted entirely rather than rendered as type="", which allows the browser to probe the MIME type itself (apparently that's the same thing YouTube and Vimeo embeds do).

Trac ticket: https://core.trac.wordpress.org/ticket/31689