dtynan

you’ll just have to remember to go make the same change again if/when they update EBD. Fortunately, they don’t update very often and the change is only one line. There’s no other way to do it that I can find…

ah, yeah, I got it. Give me a little while to take a look and I’ll post an update

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).

In the CF7 form, you need to be on the “Form” tab, not on the “Mail” tab. The “your-email” needs to go in the -form- that you made on the Form tab, not in the From field on the Mail tab.

See the 2nd image down on the Screenshots page – https://wordpress.org/plugins/email-before-download/screenshots/
That screenshot is from an older version of CF7, but you’ll see what I mean. That html form there is similar to what you’ll have in the Form tab. You need to look at the one for the email input field and make it’s name be your-email rather than Email (which is what I think it is right now).

So yours needs to look like the one on that page .. something like:
[email* your-email]
or with the akismet stuff maybe if you use that.

Ok, I don’t know if this will work or not, but I think it will — at least if you are configured for single-download (in other words, you’re not using checkboxes & multiple downoad_ids). You will need to edit email-before-download.php and change line 626 from:

$mail['body']  = $mail['body'] ."\nThe downloaded file name: $title;";

to

$mail['body']  = $mail['body'] ."\nThe downloaded file name: $title;" . " $innerHtml";

Hmm. It should be “force_download” rather than “force-download”, though I doubt that is the problem.

I don’t really know what the problem is, but here are some things to try:

Make the wordpress page public and try again … leave the page public while you try the rest of this stuff (just to eliminate that as any kind of problem .. you can make it private again after if needed).

Try it with masked/hide turned on and also try it with it off (this is in the EBD settings).

Set it to ‘both’ in the EBD settings and turn on attachments. Then, go to your form to test it and put in an email address that you know will be able to receive the email (for example, the same one you are using for the wordpress administrator emails). It is common for various mail providers like Yahoo and Gmail to block incoming emails sent by EBD, especially if you are on a shared hosting platform, because the “from” will make it look like spam. Thus, make sure you actually get the email .. you should get 1 notification email (to your wordpress admin address) and then another email to the address you put in that form (which can also be your admin address, as I said, which will help get it through probably, though maybe not). The purpose of testing with attachments is to see if the file gets attached to the email properly. If so, then we know the problem has to do with your page or theme probably.

I noticed that your URL has that geo_ip thing appended. I don’t think that will cause issues, but it just reminds me that if you have plugins that muck around with forms or file downloading or stuff like that, you might try turning them off and try again.

Finally, the last suggestion is that you create a new (public) test page. Make a new CF7 form that looks just like your existing one (the purpose of this is to get a new form id number). Get a .jpg file you have never used before and upload it into Download Monitor (we want a new download_id number here & we want a filename that is new). Make a new shortcode out of those IDs and put that on your new WP test page. Give it a try. The purpose of all that is to eliminate any chance that existing stuff in your database is messing things up (because EBD will use the existing ID numbers to pull from the DB … making a new one ensures everything is clean).

I mean put it in the “Message Body” section of the Mail tab. Just at the bottom or in with your existing text somewhere & then try again & check it & see if it got changed to what you want