Change relative URL for wp-mediaelement in _wpmejsSettings to absolute

[RussellYermal]

Line 305 of wp-includes/script-loader.php reads:

	did_action( 'init' ) && $scripts->localize( 'wp-mediaelement', '_wpmejsSettings', array(
		'pluginPath' => includes_url( 'js/mediaelement/' , 'relative' ),
	) );

This works fine when you are hosting WP's js on the same domain, but when using a CDN, as many of us are, this causes the [audio] shortcode to try to load the swf fallback from:

​http://wp-includes/js/mediaelement/flashmediaelement.swf

This causes mp3 files embedded with the WP [audio] shortcode not to work in firefox when hosting WP's js from a different domain.

Ideally, the mediaelement-and-player.min.js file can be updated to not append ​http:// to the relative URL, which would result in embedding the swf file at /wp-includes/js/mediaelement/flashmediaelement.swf instead of ​http://wp-includes/js/mediaelement/flashmediaelement.swf

However, to mend this issue in the short term, I've patched script-loader.php, line 305, to read:

	did_action( 'init' ) && $scripts->localize( 'wp-mediaelement', '_wpmejsSettings', array(
		'pluginPath' => includes_url( 'js/mediaelement/' ),
	) );

Would love a second opinion here.

[nacin]

This was done, I believe, to try to avoid issues when dealing with cross-domain setups. We'll need to make sure that not only would this fix your situation, but not break any other situations either.

[ocean90]

If it's relative, does it still work if the install is not in root? See ticket:24902:6.

[SergeyBiryukov]

Replying to ocean90:

If it's relative, does it still work if the install is not in root? See ticket:24902:6.

Yes, as long as includes_url() is used instead of a hardcoded path.

[nacin]

After looking at this for a while, I think there is a good chance that your filter on includes_url() is causing breakage, as well as causing the addition of '​http://'.

Can you share your callback that you are using to serve your JS from an external CDN?

We can't fix this in this manner — other things will break. This is also the only report we've received, and it seems to work on WordPress.com, which also offloads JavaScript.

It seems that the includes_url filter in includes_url() should receive the requested $scheme. That said, it is not difficult to deduce the requested scheme from the incoming URL — simply look for https:, http:, or / at the start of the string.

[RussellYermal]

Hey guys,

Just wanted to follow up -- sorry, I don't know exactly what code they're using as the plugin is very heavy, but the specific plugin I'm using is the extremely popular W3 Total Cache

I'm still patching this manually in WP each time a release comes out

[wonderboymusic]

This is definitely the plugin - please report the issue there.

Most CDN-aware plugins replace URLs with an output buffer, and expect paths, instead of full URLs, in JS.