Podcast tests - conclusion
31 December 2008
Well, a few more tests out of the public eye, some dialogue with my current host Heart Internet and the support of the author of Podcasting have finally led me to a better understanding of the issues with Wordpress and mp3 files and podcasting.
Here comes the technical stuff, which I hope explains what's been going on:
Firstly, Wordpress can do podcasting right out of the box. Add a url pointing to your mp3 file in your Wordpress post and Wordpress will go and look at the file, determine the type (mime type) and size and attach it to your post and RSS feed.
Hey Presto - you've just casted your pod.
Plugins for podcasting on Wordpress take this basic functionality and enhance it - usually with a focus on iTunes, an inline player and the like, but the basics are already there.
If only life were that simple
So how does it work? Wordpress doesn't know if your mp3 file is on the same server as your blog or stored elsewhere, so rather than mess about, it uses a PHP extension called cURL which can query a file on any server by going out onto the web rather than just rummaging about in local directories.
Unfortunately, this also means that, if your mp3 file is stored on the same server as your Wordpress install, cURL is going out onto the web to track down the mp3 just to come straight back in again. This is apparently known as a 'loopback connection' by those who supply hosting servers. More importantly, it is seen as a security issue.
And so Heart Internet blocks the connection. Basically, I can podcast any mp3 file I want through Wordpress as long as it doesn't sit on my server. If it is on my server, Wordpress can't identify the type and size of the podcast file because cURL has been blocked, and although the podcast will still be linked, the RSS feed will be lacking the necessary information to make it a valid feed.
Yay for Podcasting
Security is the overriding concern for all those running server farms; even if Heart Internet are the only ones blocking 'loopback connections' today you can be certain there will be more tomorrow. So, rather than kick against the pricks (that's a biblical term folks) I decided to write a little block of code which checked if the file was local, and if so get the necessary information via the usual local methods (mime_content_type() and filesize()) before rushing out onto the web using cURL.
The tests worked on my system, but I'm delighted to report that the author of Podcasting has taken me seriously enough to modify my code and include it in the next version of his Podcasting Wordpress plugin.
But what does it all mean, Jim?
At the time of writing, there are three podcasting plugins for Wordpress: Podpress, Blubrry Powerpress and Podcasting. Podpress is currently broken and in development, Blubrry Powerpress is built to integrate with the Blubrry network (and has a really annoying name) but, for the moment, Podcasting is the one to watch. The developer is on the case, listens to his users and even changes his code to suit!
Just don't bother him with any questions - he's too busy answering mine.
Comments
adam
2009.02.23 16:50
#1
Cheers for your help. I am also with heart and was having a similar problem. In my case it was a mime issue with mv4 files. These files are exported from imovie but not recognised by the mime encoders installed.
Changing the htaccess file to recognise them didn't seem to work either.
In the end I just changed m4v the mp4 and all seems ok.... but not an ideal solution.
If it helps... and for your next trick.... do you have a solution to wordpress cron not working? Heart locked out the auto running of the integral wordpress cron a few weeks ago and it is causing me a bit of angst. Ie auto backups, pinging etc not running.
Any thoughts?
adam
James
2009.02.23 20:36
#2
I've never looked into Wordpress cron. I assumed it was like Drupal's 'poormanscron' module - http://drupal.org/project/poormanscron - which gets triggered every time there's a page view and then works out whether it's time to do its thing.
So is the Wordpress cron a fully fledged cron?
Heart Internet does include proper server-side cron via the eXtend CP in some of its packages. Could you use that?
adam
2009.02.23 21:21
#3
Hi Jim, yes it should work like drupal but due, again to security, the auto triggering is stopped.
This is all to do with fsockopen function is enabled The port is NOT open!
This is what I got from Heart.... who I have to say are very helpful.
.........
Most 'cron' scripts will not work on our servers as they need to be able to make http loopback connections to the server which we do not allow.
If you site needs a cron job you can set one up via the Scheduled Taks option within the eXtend control panel.
..........
So am trying to get the cron to work via extend... as you and they suggest but as yet I am no master on this. So If anyone has a working line of code I am supposed to use... I would be most appreciative.
Ian Stanway
2009.09.29 20:50
#4
Hi Jim,
Thanks for this useful article! I too am hosted with Heart Internet and have come across a similar problem with them preventing a loopback connection for a WordPress script I was trying to get working that synchronises posts & comments on my blog with threads on my forum.
From the information I learned here I was able to learn that I could replace an fsockopen call to my server externally with 'localhost' and the script wasn't blocked by Heart and work perfectly.
Ian
Add new comment