• It seems the plugin has the opposite effect on iOS browsers with MP3s… Meaning that, when I tap the generated download link in Safari or Chrome, it essentially streams the file instead of loading it “normally”. The file doesn’t get start/end times displayed. Screenshot

    Also, we have a few MP3s that are 40-ish minutes, but they start repeating around the 3 minute mark. Shrinking the file size helped, but didn’t resolve the issues.

    Loading the files from their direct URLs works normally, so it’s not the files themselves.

    Code:
    [download label="download the audio file"]https://whatever.com/wp-content/uploads/series_part_1.mp3[/download]

    Any advice?

    https://www.ads-software.com/plugins/download-shortcode/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Drew Jaynes

    (@drewapicture)

    Loading the files from their direct URLs works normally, so it’s not the files themselves.

    This might seem obvious, but why not then just supply the direct links? Because not all people viewing will be on mobile maybe?

    The issue here really is that we don’t have any way to:
    1) Target mobile safari with a server-side script
    2) Control the way mobile safari/mobile browsers handle the forced-download headers we’re sending.

    Handling downloads for mobile devices (many of which don’t even support downloads) was not something I had remotely planned for. Sorry it’s not a better answer, but I honestly don’t have any ideas at this point.

    Thread Starter Chris.NPM

    (@chrisnpm)

    Hmm… I’m not sure why you couldn’t just detect iP(ad|od|hone) or Android in the User-Agent string then not send the download header for mobile devices.

    For now, I’m just adding an alternate download link directly to the file.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Opposite behavior on iOS with MP3s’ is closed to new replies.