Multisite Network and Byte Range support for iTunes

  • Resolved donty

    (@donty)


    9 years, 11 months ago

    Hi

    This seems to come up a fair bit but never really answered in a way that resolves things sensibly long term.

    We can use byte range header requests to serve files using apache 2.4 and WordPress but we need to use the real URL as it is Apache that provides byte-range support.

    When the requests and rewrites are handled via PHP and WordPress the option to serve byte ranges is lost. What we need is to be able to allow the podcast to send the URL for the mp3 file as the real URL so that Apache can serve it up nicely for iTunes with byte range support intact.

    For multisite the usual underlying structure will be (not real URLs!) eg:

    [audio src="http://Website.our.domain/wp-content/uploads/sites/12/2016/06/Episode1.mp3" /]

    However when I place this as the reference for the MP3 in the podcast it seems to still embed the file location as:

    [audio src="http://Website.our.domain/podcast-download/100/episode1.mp3" /]

    this then fails byte range requests.

    This is using current new install of multisite network WP and has no caching, no additional plugins on the network and none active on the site bar the SSP ones.

    Is there anything we can do without hacking core php files and trying to be creative with lots of .htaccess hack rewrites? or can we use .htaccess rewrites to do the work for the plugin itself?

    Without a tidy solution it seems really to make it non-multisite compatible plugin, which would be a real shame.

    Has anyone got this working on multisite with subdomain sites?

    Thanks

    D

    https://ww.wp.xz.cn/plugins/seriously-simple-podcasting/

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Contributor Hugh Lashbrooke

    (@hlashbrooke)

    9 years, 11 months ago

    If you use the snippet at the bottom of this document: https://www.seriouslysimplepodcasting.com/documentation/podcast-audio-will-not-play-anywhere/ – then you’ll be using the raw file URLs instead of SSP’s custom rewrites.

    The downside of this is that you will not be able to use the free stats add-on as it is impossible for WordPress to track the file downloads without using custom URL rewrites. It will, however, work for you no matter what as the files will be accessed by the URLs that you supply in the episode details instead of the custom rewrites.

    Cheers,
    Hugh

    Thread Starter donty

    (@donty)

    9 years, 11 months ago

    Hi Hugh

    Thanks for getting back to me, but that means each subsite will need child themes for each theme used for all podcasting sites across the network and network groups.

    That gets to be a real PITA for managing stuff across sites and servers.

    We can apply other stats monitoring for file access to cover that, though the stats plugin is good and convenient it is less of a task than keeping track of patches in multiple child themes as people change them. It would ultimately result in a completely separate set of child themes required for any podcasting site.

    Adding an option in the pluign at the Redirection panel to pull off the rewrite for multisite would help. The byte range is the only aspect that wont work but is essential for iTunes so it could be left as a per site option rather than creating a WPMU special?

    Do you know of anyone who has multisite offering byte range without the url hack? It is not just us is it? 🙂

    Thanks again for getting back to me, it is great when authors engage, but its not quite solved for me yet!

    D

    Plugin Contributor Hugh Lashbrooke

    (@hlashbrooke)

    9 years, 11 months ago

    You don’t need to use a child theme – just put the snippet into a custom plugin and then network activate that plugin. A small plugin like that is really basic, but you could you use what is often referred to as a Functionality Plugin to contain the code. This looks like a good option, but I haven’t looked through it properly.

    An even easier option would be to basically copy the Hello Dolly plugin that comes packaged with WordPress, remove all of the code below the comments at the top and then add the snippet in there. That kind of support is outside of the scope of what I can offer you, but it would be a pretty easy way to go about doing it.

    I don’t really know of anyone who is directly using multisite and I don’t really understand why it is presenting such an issue to be honest. That being said, I don’t really work with multisite at all, so I don’t know a lot of the ins and outs of the requirements there.

    Thread Starter donty

    (@donty)

    9 years, 11 months ago

    Thanks Hugh, all good ideas. I think some form of a plugin is an option that we could work with.

    Multisite is useful for groups and clusters of people. It is a relatively clean way to keep plugins, themes, users and controls together for connected sites and communities. But it isn’t perfect!

    Most of the issues tend to come from short-cuts or short-hand that people use in their code structure that get tripped up with the multisite DB but this problem seems different.

    It must be the way the core WP code handles the main redirect for requests for the uploads directory for the sites. I see other code where PHP can make use of the byte range option so it is possible just perhaps not within a plugin!

    If I do get any more info or solutions I will drop you a line.

    Thanks for the help and a seriously good plugin 😉

    D

    Plugin Contributor Hugh Lashbrooke

    (@hlashbrooke)

    9 years, 11 months ago

    OK great – when I’m able to do some further multisite testing I’ll see what I can polish up as well.

    If you like the plugin then it would be great if you could support continued development by leaving a review 🙂

    Cheers,
    Hugh

    Thread Starter donty

    (@donty)

    9 years, 11 months ago

    Just been digging more and found a custom redirect rule in the .htaccess that should not be needed anymore which would have affected all previous attempts! Grrr…

    Removing that and trying the previous approaches again I determined that if the URL in the podcast post for the Podcast File is set as the true URL not parsing through index.php on WP then it does work.

    ie http://Website.our.domain/wp-content/uploads/sites/12/2016/06/Episode1.mp3

    Instead of http://Website.our.domain/podcast-download/100/episode1.mp3

    Testing on castfeedvalidator it now works fine.

    I also tried changing the custom field entries to match for audio_file and enclosure but that isnt required to pass the validation.

    I then tried it on a legacy network using the old MS files redirect and it still works. URL structure is different for old Multisite:

    [audio src="http://Website.our.domain/wp-content/blogs.dir/12/files/12/2016/06/Episode1.mp3" /]

    (NB in both cases substitute 12 for your blog ID number for the site)

    This avoids the use of any re-coding and messing with plugins.

    So now iPhones and others will be able to resume downloads and fill in the gaps and there is no more hard work to do.

    Not sure about stats yet, will it work still as the podcast feed and other content is the same? What might I miss?

    Essentially it is like hosting files externally like soundcloud etc but not sure how the stats will account for things?

    D

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Multisite Network and Byte Range support for iTunes’ is closed to new replies.