dtynan

Edit the CF7 form that you created and change the field names to “your-email” for the email field and “your-name” for the name field (no quotes on those).

Put a url to your page in here if you want me to take a look at it.

The only other issue that I know of that may cause that behavior is if you didn’t name the email field “your-email” in the form that you created in CF7. That would be my best guess at this point. You didn’t provide a URL to your page, so I can’t be certain, but that’s probably it.

Aside from that issue, I’m guessing that it’s only sending out 1 email instead of 2 when you test (based on the fact that you only mentioned one email and also it tends to fit with the description).

To check for the “your-email” issue:

edit your CF7 form and on that first tab look find the little tags used to create your HTML form (the form website visitors see when they get to your website). You used the little CF7 special tags that are in square brackets. You did one for name and one for email and maybe some others. When you create those you can put in a name that becomes the field name in the HTML form. For EBD, the email field MUST be named “your-email” (without quotes) or things will not work right. You should also make the one for name be “your-name” (assuming you have a field for name). Save it. Assuming you weren’t using “your-email” and now you are, then that should fix that part of the problem. You can test again and it shouldn’t hang this time.

What emails EBD sends and when:

Let me explain what emails get sent out and why and we’ll see if maybe you have a second issue that you’re not aware of. This is gonna be wordy because I don’t have time to make it concise .. faster to just type a bunch at you.

Some person on the internet visits your webpage, decides he wants a free download, and so he puts in his name, email, etc. into the EBD form and hits submit. Then…

An email will be sent to whatever email address is in the To: field of the CF7 form that you created (the To: field is on the Mail tab and by default it is set to the wordpress admin email address). I call this email the notification email.

• The notification email is sent every time some visitor fills out the form & submits it — it doesn’t matter if you selected ‘inline’, ’email’, or ‘both’, in the EBD settings, the notification email always gets sent.
• The notification email almost always gets delivered properly because EBD asks CF7 to send the email & CF7 has usually has good values to put in the To: and the From: of the email (it get the values from the “Mail” tab of the CF7 form you made).
• You can identify the notification email by the fact that it does NOT have a link to the download file in it. It has some info about the visitor (the stuff the visitor typed into the form) and it has the filename or file title in it (but not as a link) so that you know what was downloaded.

ALSO, if you have ’email’ or ‘both’ selected in the EBD settings, then aside from the notification email, another email will be sent. This will be sent to whatever the website visitor typed into the email field (the your-email field, technically). I call this email the “visitor email”.

• The visitor email can be identified by the fact that (by default) it has a link in it which leads to the download file.
• The EBD plugin php code actually sends the email, unlike the notification email which is sent by CF7. Unfortunately, there is no setting in EBD where one can set the From: of the visitor email. That means that the From: will often get set to the actual unix account of the computer, which will usually be some weird account name that is completely unrelated to your domain name. That makes the email look like spam to many receiving email providers like gmail or yahoo. They will often silently throw the email away (meaning your website visitor never gets it .. not even in his spam folder). This is a very common problem.
• In order to fix the bad From: value on the visitor email, you need to install either Postman SMTP or Custom Sender For Email Before Download. You must set the From: value to be SomeRealValidEmailAccount@YourDomainName Note that you need to make sure that email address actually exists (like go into your host’s cpanel and make it or whatever).

Because of the From: issue with the visitor email, it is a very good idea to use a gmail or yahoo email account to test with when you test EBD (since they won’t deliver emails with a bad From:). And, you want the email address to be different than the email address that gets the notification email. That way, you can see that both emails get sent. If you use the same email address, then it’s easy to get confused between the two emails (or, you might just get the notification email and think that’s all you’re supposed to get, which I’m guessing is the scenario you’re going through).

NOTE:

If it turns out I’ve guessed wrong and none of the stuff above applies to and I’ve typed all that for nothing, then please post a URL to your page so I can try it and see what happens.

• This reply was modified 7 years, 9 months ago by dtynan.

You have to turn WP_DEBUG off or else make its output go to a file. If WP_DEBUG is on and it is allowed to display messages to the screen, then there is a warning message that will get intermingled with EBD’s AJAX response & corrupt it so that, rather than valid JSON, it is unreadable by the javascript on the page & thus the page can never complete.

Turn off WP_DEBUG. Or, leave it on but make its output go to a file
https://codex.www.ads-software.com/WP_DEBUG

carolateixido, the problem you’re seeing is unrelated to the previous discussion in this item, so ignore all that — doesn’t apply to you.

I’m not quite sure what’s causing the issue that you’re seeing. When your page first loads, it logs a 404 not found error for https://nubison.cl/wp/index.php/wp-json/contact-form-7/v1/contact-forms/29130/refill which I don’t think I’ve seen before.

Then, if you click submit on your form, it hangs with the spinning icon, but in reality it has received a 404 from the URL it tried to go to submit (which is basically the same as the previous URL, but without the “refill” part on the end).

It looks like this is due to the latest version of Contact Form 7. It could be a bug with them. Or, it might be something else. This support item has several people experiencing the same thing as you (they are using Contact Form 7, which is, of course, used by Email Before Download): https://nubison.cl/wp/index.php/wp-json/contact-form-7/v1/contact-forms/29130/refill

So, you might just have to wait for a fix. Or go back to the previous CF7 version like several people on that item. However, it could be something else. Rebuilding permalinks seemed to work for a few folks…

If I were you, I would make another test page in wordpress and put the CF7 shortcode in there —- note I’m saying the CF7 shortcode (which is displayed when you edit your CF7 form), NOT the EBD shortcode. Save that, and test and see if it works or not. The purpose of this is to eliminate Email Before Download and see if the problem still exists when only using CF7. If the problem does still exist, then it’s probably a bug on their end with CF7, or something funny with your configuration. I would try rebuilding the permalinks and I would turn off any security plugins or anything that might interfere like a redirection plugin or caching plugin and test again.

There is an extremely slim chance that it could be related to Divi if you’re using the builder .. never seen that happen, but just throwing it out there.

It could also be that your Chrome browser upgraded. If you trudge through the Chromium bug list, you’ll find that this problem or very similar ones were reported at one time or another. It’s possible that they fixed the problem for a while and then reintroduced it without realizing it (very possible because it’s such a specific situation).

Anyway, I don’t have any advice beyond what I’ve given, other than to say that I did try various webserver & php.ini & even hidden internal Chrome browser settings a year or so ago (when I was able to recreate the problem myself on my own set up), but never found any combination that fixed the issue.

One other thing worth mentioning is that the browser cache plays a part in this. There is a difference between how things act on the FIRST time you download a specific PDF file from the server, versus the following times (and it’s even more complicated than that because Chrome does some tricky stuff when you download the same file you just downloaded a few seconds ago vs like last week). It’s too complicated to explain, even if I could remember it & I’m not sure I ever really fully grasped how it all interacted.

If your download file is a PDF document and it doesn’t download or doesn’t completely download the file when you use Chrome, but does work when you use Firefox, then you are running into an issue that is known, but the only known fix is to uncheck the “Hide/Mask” option in the EBD Settings.

Let me explain what the Hide/Mask checkbox actually does…

With the checkbox NOT checked:

EBD will return a “Location:” header with a URL to the file (which is basically a redirect to the file). Normally Chrome will display the File Download/Save pop up box for the user to save the PDF locally (as opposed to displaying the PDF inside the browser itself). Once the user clicks save in that popup then Chrome will properly download the PDF in that case. Beyond sending the Location: header thing, EBD basically doesn’t do anything and allows the browser & the web server to handle downloading the file. As a side note, be aware that the URL to the download file will still be disguised in the initial download link displayed to the end user (the ‘inline’ link that EBD adds to the page or sends in the email) … it’s just that once he clicks on that link, the real URL will be given in the Location: header so the end user could discover the URL that way.

With the checkbox checked:

When the end user clicks the link to get the PDF file, rather than sending a Location: with the URL to the file, EBD will instead read in the PDF file itself into memory (using its own PHP code) and EBD itself sends the content to the browser. This normally works just fine with all content. However, for SOME installations the content will not download properly to the end user’s browser IF the content is a PDF file and IF the user is using Chrome with it’s internal PDF viewer. This problem does not affect every website. For some folks .. or for some PDFs .. things seem to work fine. If you watch the webserver logs & the browser traffic when the problem occurs, you can see the browser start downloading the file & EBD starts sending it, then, the browser cancels that interaction & initiates a new one & uses HTTP byte-range requests but never seems to increment them. There are old bugs open in the Chrome (Chromium) development tree related to this problem, but they never seem to have fully fixed it. My guess is that there is some combination of PHP settings and/or webserver settings and/or specific byte strings in the PDF that trigger this condition in the Chrome internal PDF viewer (since it does not happen with every PDF or with every website).

So, in the end, if you encounter this problem, there is no known solution at this time, but you can workaround it by unchecking the Hide/Mask setting in EBD.

I tried your page and didn’t run into any problems. I was able to get a link displayed inline on the page and that link let me download the PDF. Likewise, I also got an email with the link which also worked. The download is a 37 page PDF file that starts off with Dave Sinclair Buick GMC.

My best guess is that you are getting the 404 because it’s giving you the same bad link every time you test because it’s in the database that way. You could try testing with a different email address typed into the form & I suspect that would work. If you want to fix it for the email address you’re currently testing with, then you probably want to do something like:

Go to CF7 and “duplicate” your Form. Note the ID of the new Form you just created.
Go to your wordpress page and change your shortcode to use the ID of the new CF7 form you created. Save it
Test again and see if it fixed it.

If that still didn’t work then try clearing any wordpress caches and clear your browser cache too.

First, turn off WP_DEBUG. Or, if you want to leave it on, then you need to make its output go to a file rather to the screen. EBD will not work properly if you have WP_DEBUG on and let its output go to the screen (which is the default, typically). I suggest turning it off until you get things working — then you can turn it on & make output go to a file if you so desire.

The settings that are accessible in CF7 (like From and To and so on) are for the “Notification Email” (the email that tells you that some visitor has come to the website & filled in the form & downloaded the file). The Notification Email typically tells you what was downloaded, but doesn’t have a link to download the file.

When you are set to “both” or to “email” in the EBD settings, then EBD will send an email to the email address that the website visitor typed into the form when he visited your website. That email often does not go through to the visitor because the From: is often incorrect. In order to set the From: value on that email, you need to either installed Postman SMTP plugin and set that up (that’s what most folks do) or install the Custom Sender For Email Before Download. In either case, you need to make sure the From value is a valid email address for your domain name.

Where/how did you set the From: of the email?

So, you are set to ‘Both’ in the EBD Settings, right? (as in Both an inline link and an email)

And you’re sure the email part worked before now? How long have you had it working .. like a couple of days, or weeks, months?

Normally, when you’re set to ‘Both’ or set to ‘Email’ then EBD is going to send 2 emails out. Typically, one goes to the WordPress Admin (I call this the “notification email” — it does not have a link in it, it just tells you that someone downloaded the file). And the other email goes to the email address that the website visitor typed into the form when he went to the webpage on your website (that email should have a link in it for the download). That first email (to the wp admin) almost always arrives just fine. The second email sometimes doesn’t for various reasons. Are you getting the first email (the notification email)? I just tried testing your form many different times – you should have received a bunch of emails for those, hopefully.

Answer those questions in here, please.

In the CF7 form that you created, you MUST name the email field to be “your-email” (without quotes). Currently, yours is something like cf7a-email-address or something like that. You need to edit your CF7 form and make the email field be your-email. You may also want to make the name field be your-name. That’s not required, but it helps so that whatever the visitor types into the name field on the form when he visits your website will make it into the “name” field in the CSV file (that you can export from the top of the EBD settings page in your wordpress).

the field name for the email field in your CF7 form MUST be “your-email”. If it is not your-email, then things won’t work. See the screenshots (I think it’s the 6th screenshot .. you have to scroll to the right a little bit to get to it) on the EBD description page on this website.

babken,

I just tried your page using both firefox & chrome and in both cases it appeared to work, at least as far as submitting the form & getting a message on the screen saying that a message had been sent. That said, I will note that a whole bunch of requests to wc-ajax/get_refreshed_fragements were logged alongside the ajax POST request that the EBD form does when you submit it. Those wc-ajax calls were getting 301’s. So that is all weird. wc-ajax has to do with WooCommerce, so it looks like WooCommerce’s ajax handling may be interfering with things. However, it did at least work up to that point & I did receive an email with the link to the download.

When I click the link to the download, I eventually end up at your homepage. Clicking the link leads to the proper EBD program (download.php), which is giving a 302 redirect to the file location in Download Monitor (which is /test/0/ on your system) and for some reason that is giving a 302 redirect back to your homepage, which is odd. It looks like maybe the download in Download Monitor is not working right.

Normally, if you edit your download in Download Monitor, then on that edit screen over in the top-right area you’ll see a space for a URL and that URL is the URL for your download (you should be able to paste that URL into a browser & download your file … if that doesn’t work, then your download set up or download file in Download Monitor is not working right). So that could be the issue.

Rather than delivering a 302 redirect to where the file is (/tests/0/), EBD can also directly read the file off the filesystem & deliver it back to the browser. You can control which behavior you get by checking or unchecking the “hide/mask” option in EBD.

So, if I were in your shoes, the first thing I would do is check my download file as I described above & see if I can get the URL and paste it into a browser and get the download file. If that doesn’t work, then my issue has to do with the download file or with something else interfering (look woocommerce).

If I’m able to download the download file ok using that direct URL, then I would go into the EBD settings and check the “hide/mask” option and then test the form again and see if that fixed things.If it does not, then something else, like woocommerce, is interfering.

Probably because it has tons of error messages & warnings in it.