WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 5 months ago

#25227 new defect (bug)

Change relative URL for wp-mediaelement in _wpmejsSettings to absolute

Reported by: RussellYermal Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.6
Component: Media Keywords: 2nd-opinion reporter-feedback
Focuses: Cc:

Description

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.

Change History (7)

comment:1 SergeyBiryukov8 months ago

  • Keywords has-patch removed
  • Milestone changed from Awaiting Review to 3.7

comment:2 nacin7 months ago

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.

comment:3 follow-up: ocean907 months ago

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

comment:4 in reply to: ↑ 3 SergeyBiryukov6 months ago

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.

comment:5 nacin6 months ago

  • Keywords reporter-feedback added

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.

comment:6 nacin6 months ago

  • Milestone changed from 3.7 to Awaiting Review

comment:7 RussellYermal5 months ago

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

Note: See TracTickets for help on using tickets.