Did the audio player come from an oEmbed process? The post content just had the mp3 link and oEmbed made it into a player?
The oEmbed process runs before shortcodes are expanded, and when the shortcode expansion process runs, it is not setup to find shortcodes in audio player attributes, so yours is ignored.
What might work is to hook the ‘oembed_result’ filter and extract just the URL itself from the content. Use do_shortcode() on the URL to get the current user, then replace the original URL with the expanded version.
Hi bcworkz,
I tried the above code, but was not sure if the filter was fired. Is there a way other than using an alert in the short code function to tell me it fired? Failing which, I guess I will create a new shortcode which will return the entire html for audio with the attributes adjusted.
Cheers,
dion
Put a line like wp_die('oembed_result filter fired'); in your filter callback.
Outputting an alert doesn’t work if the browser is not expecting output yet. Dying forces the situation. Drastic but reliable. There’s a few other techniques for debugging this sort of thing. Sometimes assigning debug output to a global which is then output at an appropriate time like during the ‘wp_footer’ action will work, but it’s not 100% reliable.
Using error_log() will work if you can readily access your error log file. This is not possible with some hosts, and the log file will not accept the large data dumps that are sometimes required when investigating hacks. Outputting data to a log file of your own making allows much larger data dumps. Instead of writing to a file, you could email yourself the data with wp_mail(). If you’re developing on localhost you may not have a functioning mail server though.
Good luck!
