The download works for Firefox and other browsers — just not Chrome.
What you’re seeing is some sort of bug with Chrome’s built-in PDF viewer or with Chrome itself in how it handles files sent with a correct mime type (like “application/pdf”) but from a program (like download.php) or from a program with a query string on the end of the URL.
One other person on here ran across the same problem a few weeks back. Also, I have been able to reproduce the problem on my own server. There are a couple of ways around it, though none are perfect.
Option A
This is a little complicated…. So, the problem does NOT occur if the PDF is sent from the server with headers that cause Chrome to cache the file in its browser cache. This is why many people do not see the problem. There are a couple of exceptions to that. First, if the user has disabled his browser cache in his preferences (or in Developer Tools or via plugin) then the problem will occur. Also, if he reloads the page by holding the Shift key and clicking the reload icon then that bypasses the browser cache and thus causes the problem to appear. Ok, so what all that means is that the URL with the download.php?somelongstringofcharacters WILL work for almost everyone as long as you setup headers to cause the pdf file to make it into the browser’s cache. On your site, you are sending back an Expires headers that is some date in 1980. Thus, the browser cannot cache the file. If you instead set the Expires header for PDFs to be a month from the time the file is accessed or a year from the time the file is accessed, then it will probably work. That said you have quite a few cache-related headers that I don’t recognize or that I don’t remember being valid for Response headers (as opposed to Request headers), so you might need to do more than what I just said. Anyway, if none of this makes any sense, then you probably don’t want to go this route. If it does make sense then you can try fixing your Expires header and that might be enough. In Apache, if you have mod_expires going, then you’ll need a stanza like
ExpiresByType application/pdf A31536000
which would expire the pdf a year from now. Obviously don’t set it that far out if you plan on changing the content of that pdf and keeping the same filename. I think you’ll need:
ExpiresActive on
as well, if you don’t already have it.
Option B
If you add:
force_download=”true”
to your shortcode, then instead of trying to display the PDF inside Chrome using the internal PDF viewer, it will instead pop up a file save box and allow the user to save the pdf file. That will avoid the problem, but might not be what you want. I think modifying the shortcode is enough to make it do the file save box, but if it doesn’t then also turn of hide/mask.
Option C
If you turn off hide/mask in the EBD settings and you put your download file in an accessible directory then EBD will do a “Location:” to the file location rather than trying to read the file & send it to the browser using php. By doing a Location: the browser will go get the pdf file and it will display properly. However, the user will be able to see what the URL to the file is once it shows up in the PDF reader. That may not matter to you .. if not, then this is a good solution. Earlier when I said you have to put the download file in an “accessible directory”, what I mean is that your pdf file is probably in dlm_uploads (which is where Download Monitor put it when you uploaded it). However, dlm_uploads may be protected so that people on the net can’t get to it. If so, then can copy the pdf over to like the regular uploads directory and then modify the URL path in Download Monitor for that download so that it points to the new location).
