Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Tried in Firefox, IE, Chrome.
CentOS
Apache built with Zip
Drupal 7.23
PHP 5.420
No error messages in the log, but no file downloads. CSV or XLS makes no difference.
For no good reason I suspect batch/background batch interference?
Comment | File | Size | Author |
---|---|---|---|
#27 | webform-progressive_batch-2101643-27-D7.patch | 2.49 KB | Liam Morland |
#21 | 2101643-21-webform-export.patch | 2.57 KB | hey_germano |
| |||
#19 | webform_fix_download-2101643-19.patch | 2.13 KB | amourow |
| |||
#13 | webform_fix_download-7404-12.patch | 488 bytes | chrisroane |
| |||
#9 | webform-fix_downloads_with_background_process-2101643-9.patch | 2.96 KB | seanB |
|
Comments
Comment #1
derekw CreditAttribution: derekw commentedOh and it's a relatively simple webform with only 11 responses so far.
It does use Select or Other.
Comment #2
.kuma CreditAttribution: .kuma commentedSimilar issues here; downloads for the most part are failing; when they do download the file is blank.
Comment #3
quicksketchI wonder if this is a PHP 5.4 issue? What version of PHP are you using @.kuma?
Comment #4
froboyI've seen this a few times too. PHP 5.3.10, Webform 4 beta. Sometimes downloads fail and sometimes they succeed. I can't find any rhyme or reason as to why.
Comment #5
DanChadwick CreditAttribution: DanChadwick commentedClosing as cannot reproduce. Note that there was an issue with IE8, if that helps. Please re-open if you can consistently reproduce this issue.
Comment #6
Exteris CreditAttribution: Exteris as a volunteer commentedIn our case, disabling the background batch module fixed the problem. See #2405027 for more info.
Comment #7
wstocker CreditAttribution: wstocker commentedI am seeing the same thing with my install of Webforms
Webforms module version: 7.x-4.1
PHP 7.0.8 and 5.6.10
Drupal 7.51
MAMP Stack and Pantheon Sites (nginx)
No errors in the console, mysql log, apache log, php log or dblog and when I hit submit to download the results I am redirected back to the homepage.
When I rollback the function webform_results_download_form_submit in webform.report from Webforms 3 I am seeing the download to my browser just fine.
So I assume there is a problem with the batch operation or I am missing something.
I am seeing a file being written to my tmp directory, but with nothing in it.
(This is my first time submitting a comment so sorry if there are any issues with it.)
***Edit: As soon as I added the following code under batch_set($batch) in webform_results_download_form_submit it worked:
$batch =&batch_get();
$batch['progressive'] = FALSE;
batch_process();
Comment #8
Liam MorlandDoes this happen consistently? Does it happen on the latest development version of Webform? Can you provide your code as a patch?
Comment #9
seanBI can confirm this happens when you have the background process module installed. The background processes run with a different session, so the batch results are not accessible to the actual user.
We can fix this by saving the batch results in the user object. It's not perfect, but I think it's not that bad. Patch is attached.
Comment #10
Liam MorlandIs this solution a hack or is this the way background_process is supposed to work? What are the steps to reproduce the problem? Does it happen on the latest development version of Webform?
Comment #11
seanBThis happens on the latest dev version as well. Just install the background process module and try to download submission as excel or csv. The background process module will handle the batch API tasks in a background process and will have a different session as the actual user trying to download the file. Since you do have access to the user object, saving the batch results there seems to make sense.
Imho it is not a hack just a solution to the way the background process module handles the batch API tasks.
*edit
You need to specifically install the background_batch submodule for this issue. Copied the description below to make it more clear what the module does:
Comment #12
Liam MorlandThanks. This looks like a sensible solution. Has anyone else tried this?
Comment #13
chrisroane CreditAttribution: chrisroane commentedI tried the #11 patch, but it didn't work, but what WendyA posted in #7 worked for me. I created a patch and confirmed this works with the latest stable version of the module. Attached is the patch file.
I'm not 100% sure exactly what this code is doing or why it makes it work, but it does the trick for us. We are using PHP 7.
Comment #14
Liam MorlandSuch a patch would require comment explaining what it is doing and why it helps.
Comment #15
joelpittetWorks though.
Comment #16
Liam MorlandThis needs a comment explaining what it is doing.
Comment #17
Yaremchuk CreditAttribution: Yaremchuk commentedAs I understand, patch #13 turn off butch and perform the action in a regular way.
Comment #18
amourow#13 can resolve the issue as our situation is running on multiple containers with Pantheon and is similar to #7
The batch processes may run in different containers and try to get the tmp file in the batch process before the file gets shared in all containers.
A setting that allows user to turn batch on/off will be helpful for similar situation.
Comment #19
amourowBased on #7 and #13. I'd like to add an advance option in webform settings.
Comment #20
amourowComment #21
hey_germanoReviewed #19, code looks good, I just made a few small edits. This version modifies the help text for clarity and adds a variable_del on uninstall for webform_export_progressive_batch.
My understanding (which may be off) is that this patch works because tmp path can vary from one request to another on a load balanced environment. This can result in empty/malformed export files. With the progressive method, each request may hit a different webhead, but the non-progressive option executes the batch in one pass.
Comment #22
sparklingrobotsTagging for Seattle2019 contribution day.
Comment #23
jenlamptonPatch in #21 still applies with fuzz to 7.x-4.20.
Comment #24
Liam MorlandBackground Batch module has been superseded by background_process module.
Does it still work the same way with background_process? Does the problem only happen when background_process is installed? Does it always happen when background_process is installed? If these are both true, then instead of having the
webform_export_progressive_batch
variable, it could just usemodule_exists()
.Comment #25
amourowIn my case, this issue happens without the Background Process module.
Comment #26
jenlamptonI'm in the same boat as @amourow: I do not use Background Batch or Background Process, and still have this issue. Patch in #21 still applies with fuzz to 7.x-4.21.
Comment #27
Liam MorlandHere is a slightly updated patch. Please give a final test.
Comment #28
jenlamptonThis updated patch still works for me, and for those who need it, it also applies (with some fuzz) to webform 7.x-4.23.
Comment #30
Liam MorlandThanks everyone
Comment #31
Liam Morland