Mediaelement.js wordpress plugin and bwp-minify (Better WordPress Minify) issue — what’s going on and how to fix it +

While working on a largeish WordPress powered site recently (yeah, the advertising is abysmal but I can’t really do anything about it), I stumbled upon an issue with bwp-minify and mediaelement.js plugins. When using them both, video playback on certain platforms/browsers doesn’t work. Read on to find out what’s going on and how to apply a simple fix for the issue.

Setup

• A wordpress-powered site with bwp-minify and mediaelement.js wordpress plugins installed and activated
• A [ video src="whatever.mp4" ] (video shortcode) inserted in a post/page which ends up falling back to the flashmediaelement.swf or silverlightmediaelement.xap component for whatever reason (no native <video> browser support, video format requires it, explicitly specified…) — can happen often, actually
• bwp-minify (possibly other minifier plugins too) defaultly configured so that it ends up modifying/filtering mediaelement plugin’s <script src="..."> attribute (in order to correctly point the .js file to the minifier/gzip component)

Result

No video playback :/
The reason being that mediaelement.js ends up trying to load the .swf/.xap file through the bwp-minify plugin.

Why

Mediaelement.js’s default handling of the pluginPath option scans loaded <script> elements on the page for known filenames (in mejs.Utility.getScriptPath()) and appends the required playback plugin component filename to the found script path.

So, due to bwp-minify doing what it does, we end up with a flash object/embed which fails to load the required flashmediaelement.swf (same thing happens with the silverlight counterpart).

Possible workaround

If you’re not the type of person to dig into the code and apply the simple fix described below, you can work around the issue by excluding mediaelement plugin’s .js files in bwp-minify options (and loose the benefits of automatic minification/gzip of mediaelement’s javascript and css files).

However, mediaelement.js has an option that can help us fix this, but it’s not being set in the current (2.5.0, currently also the latest) version of the wordpress plugin.

The fix

Modify mediaelement-js-wp.php plugin file to set the pluginPath option. This avoids running mediaelement.js’s getScriptPath() and explicitly sets the proper URL to the folder containing required flash and silverlight files.

Find this in 2.5.0 version of mediaelement-js-wp.php:

$('#wp_mep_$mediaElementPlayerIndex').mediaelementplayer({
	m:1
	{$loop_option}
	{$controls_option}
	{$audio_size}
});

And replace with this:

$('#wp_mep_$mediaElementPlayerIndex').mediaelementplayer({
	pluginPath:'{$dir}'
	,m:1
	{$loop_option}
	{$controls_option}
	{$audio_size}
});

Important!: If you’re going to copy-paste just the extra pluginPath line, don’t forget to also add the comma before the ‘m’ key. If you have to ask why, perhaps you’re better off just using the workaround or waiting for a plugin update.

What we’re doing here is super-simple: the plugin already has a variable called $dir which contains the URL to the location of plugin files (and is using it for the same purposes elsewhere in the code) — we’re just re-using it to add an extra key to the generated Javascript configuration object.

I’d fork and submit a pull request, but I don’t think the wordpress plugin repo exists on Github (can’t find it).

Hopefully, the plugin author will include the fix in some future version, along with an updated mediaelement.js itself (wordpress plugin version is currently at 2.5.0, and the official mediaelement.js is at 2.6.5 — flash fullscreen feature along with a few importanitish bugs squashed would really be nice — until then, manual merge ftw!)