Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
tru_podcast plugin problem: Broken file URLs in 4.0.5
Summary: Upgrading from 4.0.4 to 4.0.5 broke some of my links. I haven’t read any code, but this appears to be caused by a change in how file URLs are generated.
Details: I publish a podcast using the excellent tru_podcast plugin. Here’s a representative episode. In this article, the links “my solution, recorded at an actual piano” and “Download only this episode” are generated by a tru_podcast tag, which I’m told calls through to a Textpattern function to return a file URL. In 4.0.4, these links used to point to:
http://www.schmonz.com/file_download/20070326-schumoreske.mp3
In 4.0.5, they point to:
http://www.schmonz.com/file_download/9/20070326-schumoreske.mp3
Which is fine, but the old URL no longer downloads the file or redirects to it. So external links, bookmarks, cached RSS feeds, and saved email messages pointing to this file now have dangling references.
Workaround: To ensure that my old published URLs continue to work, I can add the necessary HTTP redirects to my web server config.
Question: Is this a bug in 4.0.5 or a bug in my expectations?
Last edited by Sencer (2007-07-05 21:37:13)
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
You say the links are generated by a plugin (tru_podcast), so you should ask in the topic of the plugin about it, or contact the author. Textpattern itself never supported urls like
“http://www.schmonz.com/file_download/filename” – only links with an id in them (to which we now append the filename at the end). So it’s definitely a plugin-issue.
Last edited by Sencer (2007-07-05 21:36:43)
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
I should have mentioned that I discussed the problem with the plugin author before posting here. He said “I’m relying on a TXP function to generate the URLS, and that function changed. Given that the old numberless link doesn’t work any more, I don’t think there’s anything I can do – TXP handles the file serving, and they must have changed how it works.” That’s why I thought it’d be a good idea to ask here.
I’m pretty sure the “http://www.schmonz.com/file_download/filename” URLs worked in 4.0.4 without tru_podcast in the mix. Was this an unintended feature of Textpattern?
I guess what irks me is that this change in behavior is really surprising for a “teeny” release. Were it a “minor” or “major” release I’d expect to have to evaluate the new version carefully before upgrading. But to me, point upgrades signify security fixes, bug fixes with low likelihood of fallout, the sort of update you just apply because nothing’s going to break. Is this the model Textpattern is following?
Maybe I’m overanalyzing. Did this “feature” not ever really exist? Why did I think it did? :-)
Thanks,
- Amitai
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
I dug a little deeper – tru_podcast is manually generating the URLs with the filename in them. Sorry to mislead you earlier. If you remember, it’s because URLs without the filename were causing problems with some feed readers. It’s an option that can be turned or off in tru_podcast, and it defaults to “on”. The note from the tru_podcast source says:
When you upload a file via TXP’s “Files” interface, TXP-generated URLs that point to that file always look like “/file_download/3”, if you have clean urls turned on. Some podcast clients get confused by the number (“3”) and don’t know what name to give the downloaded file. (TXP has a broken file-download implementation.) By default, if you have clean URLs turned on, tru_podcast will generate links like “/file_download/test.mp3”. I haven’t observed any negative side effects from this choice, but if you want tru_podcast to generate the ‘standard’ URLs, switch this flag to ‘0’. Note that iTunes and a few other podcast clients seem to misbehave if you set this to ‘0’, though.
define(‘TRU_PODCAST_USE_FILENAMES’, ‘1’);
So the URL-generation is tru_podcast’s fault. Textpattern was responsible for handling the URLs, though, and that’s what broke with this release. In this case, it was an unintended feature that broke. It looks like the old “http://www.example.com/file_download/1” URLs still work correctly, implying that 4.0.5 is backwards-compatible with the intended behavior of 4.0.4.
Hrm.
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
Thinking about this more, I’m amazed that the 4.0.5 change in behavior didn’t break tru_podcast. Looking at the source, it looks like it was just a happy accident – the way tru_podcast is written is compatible with the 4.0.5 URLs. But it does make my special feature unnecessary – all the URLs should have filenames now, so iTunes shouldn’t have a problem any more.
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
schmonz wrote:
I’m pretty sure the “http://www.schmonz.com/file_download/filename” URLs worked in 4.0.4 without tru_podcast in the mix. Was this an unintended feature of Textpattern?
Indeed it was an unintended “feature”. Such urls were not generated anywhere in textpattern, hence we saw no need to test for them (or that they worked even). Otherwise you observations about minor releases are correct – we take a lot of care to ensure backwards compatibility and make minor upgrades as painless as possible. We also released an rc for wider testing by users to catch issues that we missed, before making the 4.0.5 release.
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
I’ve added the dozen necessary HTTP redirects for my old published file URLs, and life is good. Thanks to both of you.
Offline
#8 2007-07-06 22:12:57
- Logoleptic
- Plugin Author
- From: Kansas, USA
- Registered: 2004-02-29
- Posts: 482
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
Would it be possible to merge this thread with the official tru_podcast support thread? It would be easier for others to find the information there.
Offline
Re: tru_podcast plugin problem: Broken file URLs in 4.0.5
I added a post over there, directing people here. Hopefully that will do the trick.
Offline