Missing src attribute on <audio> tag prevents m4a audio files playing in safari.

[ericmulder]

We have discovered an issue where the audio shortcode doesn't work in safari. When you add a m4a file to the shortcode, and you don't use the wp-mediaelement library the <audio> tag is created without a src element. ​Safari expect a src element, and if we add one the m4a audio tag works.

We have patched this with a filter, but I think it would be better to fix this in the core.

I see that on wp-includes/media.php:3067 $html_atts are set, but no 'src' attribute is present. Shall I create a pull request for this?

Our patch:

function peek_audio_shortcode($html, $atts, $audio, $post_id, $library) {
    // check if the <audio> tag has a src attribute (use a preg match <audio src="" >). If not, get the first <source> tag
    if (!preg_match('/<audio[^>]*src\s*=\s*"[^"]*"[^>]*>/', $html)) {
        // get the first source tag
        preg_match('/<source[^>]*src\s*=\s*"([^"]*)"[^>]*>/', $html, $matches);
        $src = $matches[1];
        // now add the src="" to the audio tag
        $html = preg_replace('/<audio/', '<audio src="' . $src . '"', $html);
    }
    return $html;
}
add_filter('wp_audio_shortcode', 'peek_audio_shortcode', 10, 5);

Add the src attribute in an <audio> tag as required by safari.

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

[mai21]

@ericmulder Thanks for reporting the issue.

Reproduction Report

Description

The issue is reproducible using BrowserStack Sonoma Safari 17.3 (The m4a is displayed and not working)

Environment

• WordPress: 6.6-beta2-58396
• PHP: 8.3.6
• Server: nginx/1.24.0
• Database: mysqli (Server: 10.6.16-MariaDB-0ubuntu0.22.04.1-log / Client: mysqlnd 8.3.6)
• Browser: Sonoma on Browserstack, Safari 17.3 latest
• OS: Linux
• Theme: Twenty Eleven 4.6
• MU Plugins: None activated
• Plugins:
  • Code Snippets 3.6.5.1
  • Test Reports 1.1.0
  • WordPress Beta Tester 3.5.5

Steps to Reproduce

1. Create a page with m4a shortcode i.e

   [audio src="http://domain/wp-content/uploads/2024/06/sample1.m4a"]
   

2. Use a code snippet plugin to activate this code in additional note
3. Visit the page on chrome and play the audio => audio is working
4. Visit the page on Safari and play the audio

24. 🐞 Audio isn't working

Expected Results

1. ✅ Audio is working as it does on Chrome

Additional Notes

• To be able to reproduce, we need to make sure that no media files are in the source. We may need this code snippet to disable it. (thanks to @Boniu91 for the snippet)

//Dequeue Styles
function project_dequeue_unnecessary_styles() {
    wp_dequeue_style( 'wp-mediaelement' );
    wp_deregister_style( 'wp-mediaelement' );
}
add_action( 'wp_print_styles', 'project_dequeue_unnecessary_styles' );

//Dequeue JavaScripts
function project_dequeue_unnecessary_scripts() {
    wp_dequeue_script( 'wp-mediaelement' );
    wp_deregister_script( 'wp-mediaelement' );
}
add_action( 'wp_print_scripts', 'project_dequeue_unnecessary_scripts' );

[mai21]

Test Report

Description

This report validates that the indicated patch works as expected.

Patch tested: Adding patch code in code snippet

function peek_audio_shortcode($html, $atts, $audio, $post_id, $library) {
    // check if the <audio> tag has a src attribute (use a preg match <audio src="" >). If not, get the first <source> tag
    if (!preg_match('/<audio[^>]*src\s*=\s*"[^"]*"[^>]*>/', $html)) {
        // get the first source tag
        preg_match('/<source[^>]*src\s*=\s*"([^"]*)"[^>]*>/', $html, $matches);
        $src = $matches[1];
        // now add the src="" to the audio tag
        $html = preg_replace('/<audio/', '<audio src="' . $src . '"', $html);
    }
    return $html;
}
add_filter('wp_audio_shortcode', 'peek_audio_shortcode', 10, 5);

Environment

• WordPress: 6.6-beta2-58396
• PHP: 8.3.6
• Server: nginx/1.24.0
• Database: mysqli (Server: 10.6.16-MariaDB-0ubuntu0.22.04.1-log / Client: mysqlnd 8.3.6)
• Browser: Chrome 125.0.0.0
• OS: Linux
• Theme: Twenty Eleven 4.6
• MU Plugins: None activated
• Plugins:
  • Code Snippets 3.6.5.1
  • Test Reports 1.1.0
  • WordPress Beta Tester 3.5.5

Actual Results

1. ✅ Issue resolved with patch => m4a is working either added by media or shortcode

Additional Notes

• Tested on Chrome, Safari, Firefox and Opera

[ericmulder]

Thank you very much for validating and reproducing the bug. To clarify, when you use the wp-mediaelement packages the problem doesn't occur since that js package adds the src element to the <audio> tag. We found the issue using an in-app browser in our app on iOS (which apparently doesn't load the wp-mediaelement)

Good to see that the patch works, please take into account this is a hotfix from our side to not tinker with the WP core code and use a filter. I believe the pull request will be the permanent fix for this issue: ​https://github.com/WordPress/wordpress-develop/pull/6755

[chaion07]

Thanks @ericmulder for reporting this. We reviewed this Ticket during a recent bug-scrub session. Here's a summary of the feedback received:

1. The reporter has raised a PR that might need testing. So we are adding the keyword for this.
2. We would appreciate specific instructions for testing as the reporter says the issue doesn't occur when using wp-mediaelement packages (we suspect that we may have to manually dequeue the wp-mediaelement JS to be able to test this).

Thanks.

Props to @pratiklondhe

Cheers!

[davidbaumwald]

With 6.7 RC 1 releasing today this ticket is being moved to 6.8.

If any maintainer or committer feels the remaining work can be competed in time for 6.7 feel free assume ownership and update the milestone accordingly.

[dvershinin]

Affected by this as well, and I can confirm that the patch is working fine.

[im3dabasia1]

Test Report

Description

This report validates whether the indicated patch works as expected.
Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/6755.diff

Added this shortcode in the new post
[audio src="​http://localhost:9889/wp-content/uploads/2024/11/sample-1-1.m4a"]

Environment

WordPress: 6.8-alpha-59274-src
PHP: 8.2.25
Server: nginx/1.27.2
Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.25)
Browser: Chrome 131.0.0.0
OS: macOS
MU Plugins: None activated

Actual Results

✅ The audio tag now has src attribute in safari and the audio is playable, m4a audio clip is not playable.

Supplemental Artifacts

Video: ​https://jmp.sh/bZEleaAj

Added this code

// Dequeue Styles
function project_dequeue_unnecessary_styles() {
	wp_dequeue_style( 'wp-mediaelement' );
	wp_deregister_style( 'wp-mediaelement' );
}
add_action( 'wp_print_styles', 'project_dequeue_unnecessary_styles' );

// Dequeue JavaScripts
function project_dequeue_unnecessary_scripts() {
	wp_dequeue_script( 'wp-mediaelement' );
	wp_deregister_script( 'wp-mediaelement' );
}
add_action( 'wp_print_scripts', 'project_dequeue_unnecessary_scripts' );

[imranhasanraaz]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/6755.diff

Environment

• WordPress: 6.8-beta1-59933-src
• PHP: 7.4.33
• Server: nginx/1.27.2
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 7.4.33)
• Browser: Chrome 133.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.1
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.1.0

Actual Results

✅ Issue resolved with patch.

1. Before patch
2. After applying patch

Additional Notes

• Apply the below code to theme functions.php file before testing in safari

<?php
function disable_mediaelement() {
    wp_deregister_script('wp-mediaelement');
}
add_action('wp_enqueue_scripts', 'disable_mediaelement', 11);

[joedolson]

Did some research on the problem, since I wanted to have a better sense of what was going on here. It seems like Safari has a number of historic issues around using the source attribute, and MediaElement works around this by adding the value of the first source element as a src attribute. When MediaElement isn't running, that doesn't happen, and it doesn't work.

The current patch works *if* the m4a file is passed in the src attribute, but that isn't the case if using the media buttons in the inserter, which instead add an m4a attribute with the source.

To support that, we need to assign the primary format extension as the 'src' attribute.

[joedolson]

Because ​the content model for the `audio` element is specified as requiring *either* a src attribute or a source element child, I'm somewhat concerned this could cause problems for source type switching, and am hesitant to commit it this late in the cycle.

Moving to 6.9 so it can be more thoroughly checked.

[soyebsalar01]

## ✅ Patch Test Report

### Purpose
This report validates whether the proposed patch works as expected when applied to the current development build of WordPress.

### Patch Tested
​https://github.com/WordPress/wordpress-develop/pull/6755.diff(​https://github.com/WordPress/wordpress-develop/pull/6755.diff)

---

### 🔧 Test Details

Shortcode used in post:

`shortcode
[audio src="​http://localhost/wordpresscore/wp-content/uploads/2025/05/test.m4a"]

🧪 Environment

WordPress Version: 6.8-alpha-59274-src

PHP Version: 8.1

Operating System: macOS

✅ Actual Results

Observed in Safari:

The <audio> tag now correctly includes the src attribute.

The audio player is rendered and functional.

📌 Conclusion

Patch Status: ✅ Pass – The patch successfully ensures the src attribute is included in the <audio> tag.

Playback Issue: ⚠️ Note – Safari's inability to play .m4a persists and appears to be a browser-level issue unrelated to WordPress core.

[iamshashank]

Reproduction Report

Description

❌ This report validates that the issue cannot be reproduced.

Environment

• WordPress: 6.8.2
• PHP: 8.2.27
• Server: nginx/1.26.1
• Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.27)
• Browser: Safari 18.3
• OS: macOS
• Theme: Twenty Twenty 2.9
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. Error condition does not occurs.
2. The m4a file is playing well in safari

Additional Notes

• It’s likely working fine now either because of WordPress 6.8.2 or the Safari update improving compatibility.

Screenshots

• 
• 

[ericmulder]

Thanks for the review @iamshashank but see my comment here https://core.trac.wordpress.org/ticket/61398#comment:6

The problem only occurs when the standard js library is not loaded.

@joedolson I understand your concern, but on the other side the js library does take the first source element as well.

[SirLouen]

Replying to ericmulder:

Thanks for the review @iamshashank but see my comment here https://core.trac.wordpress.org/ticket/61398#comment:6

The problem only occurs when the standard js library is not loaded.

Ï have not dug into this issue, but judging by the last report that could not reproduce this: Which are the steps to avoiding JS library loading?

[ericmulder]

@SirLouen the js library is skipped on ios devices, or by using the code snippet provided in https://core.trac.wordpress.org/ticket/61398#comment:13

[SirLouen]

Replying to ericmulder:

@SirLouen the js library is skipped on ios devices, or by using the code snippet provided in https://core.trac.wordpress.org/ticket/61398#comment:13

This is what I was asking because @iamshashank could not naturally reproduce it with an iOS device on Safari, exactly as you were suggesting in your report.

Basically I'm checking all reports, and what they are doing is manually disabling the script.

I would rather not deregister the script to test it. I want to know how are you making that script to not show up naturally. The exact steps, the exact environment, etc., to reproduce it in my device.

I just want to keep it documented in case one day someone has to look back to see under which exact conditions this was tested (and be able to replicate it).

[ericmulder]

Thanks for the explanation @SirLouen, and I agree the test / description could have been a bit more descriptive.

TLDR; I recreated the test with an actual iOS device and the safari bug seems to be solved. Only occurs when javascript is disabled.

I've tried to create a test that is reproducible. And to make sure since the bug only appeared on iOS devices, I got our local test phone to test it out. The report form @iamshashank was on macOS.

Steps to test:
1) start a WordPress site

wp-env start

2) update the post with audio blocks:

wp-env run cli wp post update 1 --post_content='<!-- wp:shortcode -->
[audio m4a="https://labelvier.nl/wp-content/uploads/2025/08/sleep-music.m4a" mp3="https://labelvier.nl/wp-content/uploads/2025/08/motor-rev.mp3"]
<!-- /wp:shortcode -->

<!-- wp:shortcode -->
[audio m4a="https://labelvier.nl/wp-content/uploads/2025/08/sleep-music.m4a"]
<!-- /wp:shortcode -->

<!-- wp:audio -->
<figure class="wp-block-audio"><audio controls src="https://labelvier.nl/wp-content/uploads/2025/08/sleep-music.m4a"></audio></figure>
<!-- /wp:audio -->'

3) Open the post on an iPhone to test the different audio blocks:

​https://labelvier.nl/wp-content/uploads/2025/08/2025-08-05%2012.56.36.jpg

4) Open the post on a Mac and disable javascript in Safari. That's currently the only case where the m4a or mp3 is not loading.

[SirLouen]

Ok, so the problem as @joedolson commented, is that Safari seems to have troubles with source

If the element does not have a src attribute: zero or more source elements, then zero or more track elements, then transparent, but with no media element descendants.

I wonder if with some testing under different conditions and type switching this patch may cause some trouble.

[ericmulder]

Yes, although I supplied the fix myself I agree that forcing a src element in the parten <audio> tag might be tricky since I suspect it'll force the browser to use that 'source' instead of one of the other supplied <source> sources.

[iamshashank]

Reproduction Report

Description

✅ This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.8.2
• PHP: 8.2.27
• Server: nginx/1.26.1
• Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.27)
• Browser: Chrome 138.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Three 1.6
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Error condition occurs (reproduced).

Additional Notes

• ✅ The issue is reproducible on an iPhone, where the M4A file fails to play while the MP3 file plays correctly.
• 🟠 The issue does not occur by default in Safari on macOS, and I have not disabled JavaScript since typical end users are unlikely to do so.

[joedolson]

I think the big question here is, essentially, "does forcing a src attribute cause any problems?"

The main one I can think of as potential is source switching - in a browser that doesn't support the src attribute's media, does it still access the alternate format in the source element?

If, for example, we force a FLAC mime type in the src attribute, and the m4a in the source element, does Safari play the m4a? Does it require that there *is* a src attribute, or does it only play the file in the src attribute? My reading of the spec suggests that it should go to source and still play, but given that we're already operating in a not-quite-complying-with-spec scenario, we could get surprised.

The test cases to figure out the details seem pretty complicated for what is ultimately an edge case. But my general impression is that it should all work normally if we're just ensuring that the src attribute is present, without removing any source elements.

[ericmulder]

I looked into making a test case where I simulating above situation mentioned by @joedolson. But it just takes the src element, and not any mentioned source element.

Furthermore, maybe I was not really clear but I found this issue *not* occurring anymore on the latest iOS version, only on Mac OS with javascript disabled:

4) Open the post on a Mac and disable javascript in Safari. That's currently the only case where the m4a or mp3 is not loading. (https://core.trac.wordpress.org/ticket/61398#comment:24)

[joedolson]

Given the extremely limited scope of this issue and the amount of time before 6.9, I'm bumping this to a future release.