I'm attempting to use the swf() syntax in a node template to load an MP3 that's on a different domain into a generic flash player. This doesn't work, with swftools generating a file path like this (just an example):

/sites/mysite/files/example.com/path/to/audio.mp3

When the file actually appears at:

http://www.example.com/path/to/audio.mp3

I'm guessing, based on the configuration options and whatnot, that I'd only be able to do this if all my MP3s were on the same external server. Is that true? I'd love not to have that restriction.

Thanks!

CommentFileSizeAuthor
#3 swftools.patch689 byteschellman

Comments

Stuart Greenfield’s picture

You can set it at a "global" level via the settings page, by defining a media url. But that then affects all content.

To do it on a case by case basis pass a full url to SWF Tools. When it sees that it skips file existence checks and doesn't try to expand the file path as it assumes you know what you're doing :-)

So

print swf('audio.mp3');

will be expanded, according to your site file structure, but

print swf('http://www.example.com/path/to/audio.mp3');

will be processed as is.

chellman’s picture

Ah, okay, I found out what the issue was. Your code is really well documented, so it didn't take long once I looked. I also could have answered my own question if I'd tried.

I'm running on a local dev machine with a virtual host that looks a lot like the real domain. The local base URL is "http://name/" and the remote host where the site was pulling its MP3s is "http://nameword.com/", for example. The function swftools_strip_base_root() strips off the first part of the remote host because it matches the local one, so I was ending up with "sites/name/files/word.com/rest/of/path.mp3".

The solution, without modifying any code, was to add the "www." to the front of the URLs. It worked great from there.

This feels like a bug, if a rare one. I'll see if I can write a sensible patch for this.

chellman’s picture

StatusFileSize
new689 bytes

Okay, here's a solution to try. It checks that the patch returned starts with a slash, and if it doesn't, it just returns the original URL.

Assuming you think this is a bug, should I submit a separate issue for this?