dtynan

webmasterhill, the 404 error mentioned in the error has to do with your Apache configuration — you probably have configured ErrorDocument to point to an invalid file location or something like that. It’s not an issue for EBD or anything related to the download or form or anything, but you’ll eventually want to fix it since Google will count it against you (slightly) for SEO purposes (otherwise it doesn’t matter much). You can either remove that part and let Apache give its default 404 message, or you can make ErrorDocument point at a valid file or give it a message or whatever. You should get help from someone who knows Apache if this doesn’t make much sense ( https://httpd.apache.org/docs/2.4/custom-error.html )

As for the actual problem, you’re actually getting a 403 Forbidden message. That means that your file is not in a place that is accessible. Usually this is because the dlm_uploads folder or some folder above or below it has permissions that prevent the file from being accessed. Sometimes it is because of Apache configuration. Sometimes it is because of security plugins or other plugins. When EBD has “hide/masked” checked, it attempts to read the download file itself using PHP, then the PHP program sends it to the browser. When “hide/masked” is not checked, EBD does a “Location: SOMEURL”, which causes the end user’s browser to go to SOMEURL and retrieve the file. That SOMEURL for you is inaccessible. This is basically a config issue somewhere on your system — you’ll need to find your download file out in the filesystem and make sure that permissions make it accessible, or check your apache directives, etc etc etc.

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

markcode, the problem you’re seeing is specific to using a Chrome browser and viewing a PDF. I don’t ever see a 404 error, so I’m not quite sure where you’re seeing that, but there have been 4 or 5 other people that have encountered this problem over the last few months or so. If you use Firefox or IE then your page works. If you use Chrome, then most of the time it will not. The bug has something to do with the way Chrome’s internal PDF viewer handles files that are delivered with a Range: bytes header in them (which PDFs that you view in the browser window itself are). It’s unclear if the problem lies wholly within Chrome itself or if it’s Chrome interacting with the way PHP handles its output buffers or some setting in Apache or something in the PDF itself. I’ve done a lot of debug on it and never figured out exactly what the issue is. wget appears to exhibit a similar issue of downloading the file but thinking its off by 1 byte and then retrying . I tried modifying download.php content-length and the part after the range of bytes (where it does a /bytecount where bytecount is the # of bytes) to add one or subtract one from those, since programmers often mistakenly have the bytecount parameter off by one (because range starts counting at zero), but that did not solve it. Watching the internal workings of Chrome using chrome://net-internals seems to indicate that Chrome only downloads a few chunks and then starts over and does the same thing, over and over. If you look in the apache logs, you’ll see it hitting the server requesting more of the file (these are 206 http partial content), but it never seems to finish. Interestingly, I have noticed that in some situations the file download/display in Chrome will work the very first time, but once Chrome has seen it then it will never work again (this happened for others, but not for your file as far as I could see). So, it’s unclear where the bug truly lies (and the wget issue may be something else entirely), but I know it’s specific to Chrome for certain PDFs or certain environments (doesn’t happen to everyone). In the past, Chrome has had similar bugs (see https://bugs.chromium.org/p/chromium/issues/detail?id=104331 ). So, there really is no resolution to make it display the PDF in the browser. If you have this problem, your only solution is to make it download and save the pdf rather than displaying it in the browser. That is the workaround that the previous four or five people have used to get around the problem.

So, I want you to uncheck the “hide/mask” option and then update this ticket so I can go try it. I know you said you tried that, but it should fix this issue — you may have a second issue that pops up at that point, but we’ll address that when I see it. For now, please make sure “hide/mask” is NOT checked and then let me know when you have done so.

Hi cekar, sorry it took so long to reply. You updated an old item that someone else had started and the new wordpress.org support forums have a bug where they are not putting the newest updates for tickets at the top of the list. Thus, I never saw that you updated this.

I suggest you try to flipping the setting for the “hide/mask real url” in the EBD settings (if it’s checked uncheck it and retest .. if it’s not checked then check it and retest)

webmasterhill, can you take a screenshot of your CF7 form (the part with the html and such that makes the form) and put it somewhere where I can see it?

You can either install an SMTP plugin that will allow you to do it (I recommend Postman SMTP) or you can install the Custom Sender For Email Before Download plugin.

Note that, at least for me, if I resave EBD settings at any point then it wipes out the values in the Custom Sender plugin and I have to put them back in there.

yeah, if you view source on your page, then you’ll notice that you have a bunch of divs that have an id of #downloadinputform

that’s a problem. each form has a div named that and then each form has some javascript to hide or unhide that div and i’m pretty sure that that isn’t going to work right (again, probably why it always finds the first one on the page and hides/unhides it.

you would have to modify email-before-download.php to fix that. you might be able to change the selector so that it looks for #downloadinputform within the current form. or maybe put in some sort of counter so that when it creates things it does #downloadinputform1 then #downloadinputform2 and so on. Regardless, you’re gonna have to dig into that code and figure out how to do something like that .. you’ll need to know php, javascript, and css selectors to be able to do it.

Hmmm. So, first off, get rid of “hidden form”. Don’t check that. Get it working without doing the hidden form thing .. hidden form sometimes breaks things.

Secondly, I’m not sure that you can do multiple forms with the same contact_form_id. I think that’s going to cause problems. Or, maybe not, maybe it will work, but I’m not sure at the moment – for testing purposes, let’s get rid of that and then you can go back to it if needed .. so, instead, I think you’ll want to have multiple contact forms that are basically duplicates of each other, but they’ll have different IDs, so that you can do multiple forms on one page and not worry about any conflict (which, again, may not be a problem, but it might be).

So, I suggest you do this:

• make a new page (a new test page you can mess with)
• make 2 duplicates of your existing contact form (the 1185 id form)
• on the new page, put 2 EBD shortcodes on there — 1 for each of the new duplicate contact forms you just made in the prior step (do NOT put the 1185 form on that page … you want everything to be new on this new test page). Use whatever download_ids you want for each of these two new shortcodes (doesn’t matter for what we’re trying).
• uncheck the hidden form option in the EBD settings.
• now go test it and see if you see 2 forms on the page. if so, fill in and submit the first one and make sure it works, then do the second and make sure it works. Assuming both work, then go recheck the hidden form thing and try again (I’m not sure that you can do hidden form with more than one form on the page, so this may still break, but at least we’ll know for sure that’s an issue at this point).

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

There is no tag or shortcode or anything like that that is <file titles> or anything similar. That bit of text only exists in the little bit of help text underneath setting #11 in the EBD settings. It’s just trying to tell you that if you don’t put anything in #11 then it will default to the message “Requested URL for the file(s): ” followed by a list of the files. In other words, the <file titles> thing is just telling you that’s where a list of files is going to appear in the subject line. Again, there is no tag like that that you can use.

If you want a list of files to appear then you have to use [files] as the tag. So you might put something like “Here are the files you requested: [files]” in setting #11 and then that [files] will get changed to the filenames. I looked through the code and it looks to me like it should work. I couldn’t find any bugs that would cause the [files] to not work in the subject line (setting #11) but work in the body. However, I haven’t tried it, so it’s possible that it’s just a bug .. but, again, looks to me like it should work.

In order to test it, I think you should make up an entirely new message to put in #11, just for testing purposes. Don’t use anything you’ve used before. Maybe something like:
Here are some files bro: [files]
and then test it and make sure that the email you get as that first part “Here are some files bro:” in there …. maybe somehow it’s not registering your change or something.