jnm_audio plugin is a handy way of embedding audio files for playback on Textpattern sites. If you use Textpattern and publish a podcast, you’ve probably considered using this plugin. However, it has a few crippling limitations: its output doesn’t work on most smartphones and tablets, and the flash player it comes packaged with is outdated. Juanjo hasn’t updated his plugin in a long time, and no other plugin that I’m aware of has surfaced to fill the gap.
What I’ve done is hacked the plugin to fix these limitations. By that I mean, I’ve edited the code of the original, but haven’t taken time to properly repackage my modifications in plugin form; in order to use my modifications, you’ll have to do a small amount of extra tinkering. A number of people have asked for this code and I’ve said I would release it, so here’s me finally making good on my promise. However, my hope is that Juanjo or someone will take what I’ve started, and finish it up into a proper plugin.
All that said, here’s my hack. You can see it in action on my podcast’s site.
First, download the necessary files from this site. Included are:
player.swf— version 2.0 of the WordPress Audio Player
jnm_audio_0_3.txt— This is just a copy of the original jnm_audio plugin version 0.3, included for convenience
jnm_audio_replacement_code_0_1.txt— My hack, the modified plugin code
readme.md, just a Markdown-formatted copy of this post for reference.
/plugins folder in your website’s root directory, and upload the non-text files to it. (If you are already using the “old” jnm_audio, backup and delete the old versions of these files and replace them with these.)
Install the jnm_audio plugin into Textpattern using the
jnm_audio_0_3.txt file. Be sure to enable the plugin.
Insert the following code into your page template, just above the
Now for the hack. In Textpattern, go to Admin → Plugins, and click on the
jnm_audio plugin to edit it. Select all the code in the text box, delete it, and past in the contents of the
jnm_audio_replacement_code_0_1.txt file. This completely replaces the code of the original version with the modified version.
That’s it! You’re ready to use the modified jnm_audio plugin. Here’s an example of the plugin in an article form:
<txp:jnm_audio url='http://howellcreekradio.com/audio/<txp:custom_field name="Episode Slug" />.mp3' title='<txp:title no_widow="0" />' />
In this example, I’m using a custom field to set the URL for each article’s MP3 file.
There are a couple of differences from the original plugin:
- A number of the WP Audio player’s options (color, width, etc) can’t be set via the
<txp:jnm_audio>tag options anymore; to change them, you’ll have to edit the plugin’s code. This isn’t as difficult as it sounds, but it’s not ideal either.
- The new version of
player.swfrequires the title text to be explicitly set; it doesn’t just pull the title out of the MP3 like the old player did. To that end, I’ve added a
<txp:jnm_audio>for use in setting the title shown on the flash player (see the example above).
How it works
Besides using the updated version of the Wordpress Audio Player, this hack allows your files to be played on mobile devices (iOS, Android, and Windows Phone). It does this by using a better method of embedding the audio.
The embed code first creates a
<div> with an
<audio> element in it, pointing to the sound file. It then inserts a script which attempts to replace the audio element with the Flash player. Thus, on devices which support Flash, the Flash player will always be used, regardless of whether the
<audio> tag is supported. Devices which do not support Flash will fall back to using the HTML5 audio element.
You could call this the “HTML5 fallback” approach. Nearly all articles on this subject that I have seen advocate “Flash fallback”, which is the reverse approach: try for HTML5 audio support first, then fall back to Flash if necessary. This would be a good idea, except for one thing: a lot of desktop browsers support the
<audio> tag, but some (like Firefox) do not support using it for MP3 playback. So you end up having to supply another copy of your audio in OGG format, in addition to MP3, in order to be sure your audio will play in all browsers. Podcast production is complicated enough without having to bother with that.
My reasoning is this: nearly all desktop browsers support Flash, so use Flash wherever possible. The environments that don’t support Flash are almost all mobile devices (or Mac users who read Daring Fireball), and those environments almost all support MP3 playback within
<audio> tags. Flash-first isn’t a purist’s strategy, but damned if it doesn’t work perfectly every single time.