[dhrupo]

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

Summary

wp_audio_shortcode(), wp_video_shortcode(), and the media modal's MediaDetails.prepareSrc() append an auto-incrementing &_=N argument to every media source URL. The workaround dates from the WP 3.9 MediaElement.js integration and, as researched on the ticket, no longer applies now that the Flash fallback has been removed. Mutating every URL unconditionally breaks sources whose URL must stay intact, most notably signed URLs from CDNs.

Fix

Per the maintainer's review, remove the query-parameter additions entirely:

• Drop add_query_arg( '_', $instance, ... ) from wp_audio_shortcode() and wp_video_shortcode().
• Remove MediaDetails.instances / prepareSrc() from the media modal and update its three callers (audio details, video details, attachment details) to pass the element straight to MediaElement.js.

Testing

Environment: WordPress 7.2-beta4-65231-src nightly, local Docker environment, Chrome. Reproduced the original scenario from #26779 live: two [video] and two [audio] shortcodes, each pair sharing one self-hosted src, preload="metadata", on one page.

• Before (trunk): the two sources per pair are ...small-video.mp4?_=1 and ?_=2.
• After (PR): all four source URLs are identical (...small-video.mp4, no &_=N), and all four players still play — each advanced ~1.7s in a 1.8s play window driven through the MediaElement.js API.
• Admin: the media grid details player and the media modal audio/video previews (the removed prepareSrc() callers) still render and play, with no console errors.

vendor/bin/phpunit --filter "test_wp_audio_shortcode|test_video_shortcode_body|test_wp_video_shortcode" tests/phpunit/tests/media.php → OK (12 tests, 42 assertions). The one expected-string change is in test_video_shortcode_body().

Use of AI Tools

AI assistance: Kimi (Moonshot AI) drafted the patch and the scripted reproduction; I reviewed every change, reproduced the issue on trunk, and ran and verified all results myself.

---

Proposed commit message

Claude reworked this commit message to lead with the problem:

Media: Stop adding a cache-busting query arg to media source URLs.

The audio and video shortcodes and the media modal appended an auto-incrementing `_=N` query arg to every media source URL, which breaks URLs that must be requested exactly as given, such as signed URLs from a CDN. The arg was added in 3.9 to work around a browser bug where a second player with the same source and `preload="metadata"` never loaded. Chromium fixed the underlying bug later in 2014, and players sharing a source now load and play without the arg.

Output source URLs unchanged from `wp_audio_shortcode()` and `wp_video_shortcode()`, and in the media modal. This removes `wp.media.view.MediaDetails.prepareSrc()` and `MediaDetails.instances`; code calling `prepareSrc()` directly should pass the element to MediaElement.js instead.

Follow-up to [27420], [27519], [27520].

Props dhrupo, gddrt, abhishekfdd.
Fixes #66639.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props dhrupo, adamsilverstein.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[adamsilverstein]

@dhrupo Thanks for the PR! Lets remove the query parameter additions entirely, see https://core.trac.wordpress.org/ticket/66639#comment:6

[dhrupo]

Thanks for the direction @adamsilverstein — revised to remove the query parameter additions entirely:

• PHP: dropped add_query_arg( '_', $instance, ... ) from wp_audio_shortcode() and wp_video_shortcode().
• JS: removed MediaDetails.instances / prepareSrc(); the audio details, video details, and attachment details views now pass the element straight to MediaElement.js.

Re-tested the original #26779 scenario live on the 7.2-beta4 nightly: two [video] and two [audio] shortcodes, each pair sharing one self-hosted src, preload="metadata", on one page. Before: sources are ?_=1 / ?_=2. After: all four sources are identical with no &_=N, and all four players still play (each advanced ~1.7s in a 1.8s window through the MediaElement.js API). The media grid and modal players also still render and play with no console errors.

PHPUnit media shortcode tests pass (12 tests, 42 assertions); the one expected string updated in test_video_shortcode_body().

[adamsilverstein]

I guess audio files were also affected!

[dhrupo]

Yes — same story on the audio side. prepareSrc() was also mutating the audio sources in the media modal (this file was one of its three callers), and wp_audio_shortcode() appended the _= argument too. The removal covers both, so signed audio URLs stay intact as well. The latest commit (53a6770) is the full removal you asked for — no query parameter additions left anywhere.

[adamsilverstein]

Nice work!

[adamsilverstein]

Thanks @dhrupo - adding a couple of additional reviewers here that are familiar with media in case I missed something.

[adamsilverstein]

Hey @dhrupo, thanks for the quick update! Before committing I wanted to check whether anything in the plugin directory calls prepareSrc() directly, so I searched the plugin repository using https://veloria.dev/. I doubted there was any usage, but it turns out there is.

I had Claude search the plugin and theme directories for callers:

Searching Veloria for prepareSrc (https://veloria.dev/search/dcb9ab3b-f714-442f-9082-35c91c37bad8) finds 30 plugins and 1 theme calling wp.media.view.MediaDetails.prepareSrc() directly.

The source is Meta Box (500,000 active installs), which calls it in js/media.js and passes the return value straight to MediaElement.js:

var el = media.view.MediaDetails.prepareSrc( elem );
that.players.push( new window.MediaElementPlayer( el, media.mixin.mejsSettings ) );

The other 29 plugins and the theme each bundle a copy of that same file, eg. WP Contact Slider and WP-Stateless.

With the method removed that line throws a TypeError, so the audio and video previews in Meta Box media fields would likely break. This is from reading the code, it has not been tested with Meta Box installed.

Keeping prepareSrc() as a deprecated no-op that returns the element unchanged avoids the break and still fixes the signed URL issue. Something like:

},/** @lends wp.media.view.MediaDetails */{
	/**
	 * Formerly appended a cache-busting query arg to each media source.
	 *
	 * @deprecated 7.3.0 Returns the element unchanged.
	 *
	 * @param {HTMLElement} elem The HTML element containing the media sources.
	 * @return {HTMLElement} The unchanged element.
	 */
	prepareSrc : function( elem ) {
		return elem;
	}
});

MediaDetails.instances can still go, a search for it finds no usage in plugins or themes. The three core callers can stay as they are in the PR, passing the element directly.

Can you add the no-op back? I'll update the proposed commit message to match once that is in.

[dhrupo]

Good catch, thanks for checking Veloria — added back in c1d3c59: prepareSrc() is now a deprecated no-op returning the element unchanged, and MediaDetails.instances stays removed. The three core callers are unchanged. Verified live on the nightly: Meta Box's call pattern (prepareSrc(elem) → new MediaElementPlayer(el, ...)) no longer throws and the source URL stays untouched; the media grid and modal players still render and play.