Download stalls in chrome and others

I have just experienced this problem as well. I do not know the cause but I unchecked the URL hiding feature (cURL) in email-before-download and that seemed to resolve the issues. I prefer to hide the URL but it is a quick work around. Please let me know if you find the reason for this problem.

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.

Thank you for the reply and the detailed explanation. This workaround does indeed fix the problem so all is good for now. What’s strange about my particular installation is that it was working a few weeks ago and now it has started to have this problem. I’m guessing, since i’m on a shared server that the PHP version or settings got changed globally in a way that made this behavior apparent. I did do a check that cURL is available and that part looked enabled. Do you have any guidance on PHP versions that may relate to the problem?

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.

Hi @dtynan,

Can I ask you something similar?

I have the same situation than @dirtymedium.
This is my site:
https://nubison.cl/wp/index.php/airwatch-soluciones-moviles/
When clicking “DESCARGAR DOCUMENTO” it goes to the contact form and when clicking SEND, Chrome, Firefox and Edge are getting the spinning wheel.

What could be happening?
It did work a month ago…

Thanks!

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.

I too am having this issue amongst others.

I am also having the following error sometimes too Notice: Undefined variable: wp_dlm_db in /home/websiteaddress/public_html/wp-content/plugins/email-before-download/index.php on line 38
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘WHERE id = 569’ at line 1]
SELECT * FROM WHERE id = 569;

Warning: Cannot modify header information – headers already sent by (output started at /home/websiteaddress/public_html/wp-content/plugins/email-before-download/index.php:38) in /home/websiteaddress/public_html/wp-content/plugins/email-before-download/index.php on line 47

I cant seem to be able to update the pluggin at the moment either Im currently working on version 3.6

https://www.petrel-ex.co.uk/product-detail/led-area-light/

on the technical form

any help people can give would be great

lauraandcelia – the problem on your site is caused by having WP_DEBUG turned on and its output is allowed to go to the screen. That causes a problem when the form is submitted because the page expects to get back a JSON response and what it actually gets back is the JSON response but with that error/warning message that you’re seeing stuck on the front of the JSON. That corrupts the response and causes the page to hang.

You need to either turn WP_DEBUG off or else make it’s output go to a file (see https://codex.www.ads-software.com/WP_DEBUG ). Either solution will fix that issue.

Note: To be clear, the problem is caused by the error message itself — the actual problem that is causing the error message can be ignored (it’s not important).