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.I am getting error messages when exporting from some Webforms.
Delimited text export:
Warning: fseek() expects parameter 1 to be resource, boolean given in webform_results_batch_eof() (line 1160 of /.../webform/includes/webform.report.inc).
Microsoft Excel export:
Warning: fseek() expects parameter 1 to be resource, boolean given in webform_results_batch_eof() (line 1160 of /.../webform/includes/webform.report.inc).
Warning: fseek() expects parameter 1 to be resource, boolean given in webform_exporter_excel_xlsx->eof() (line 127 of /.../webform/includes/exporters/webform_exporter_excel_xlsx.inc).
Warning: fwrite() expects parameter 1 to be resource, boolean given in webform_exporter_excel_xlsx->eof() (line 128 of /.../webform/includes/exporters/webform_exporter_excel_xlsx.inc).
Warning: unlink(/tmp/webform_gtU8xP): No such file or directory in drupal_unlink() (line 2234 of /.../drupal7/includes/file.inc).
With Excel, the resulting file is invalid.
I had though this might be the same as #2201489: Results export failing when Background Batch module enabled, but that seems not to be the case.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | webform_2202499_remove_error_suppression.patch | 2.54 KB | Liam Morland |
Comments
Comment #1
quicksketchSo those particular lines are these:
It seems like fopen() is probably failing at opening the file, so the Boolean FALSE is returned. You might try removing the leading @ from fopen and see if PHP gives you a more useful error message (i.e. access denied or file not found). Is this with a stock installation of Webform? The download is functions correctly in my testing.
Comment #2
quicksketchComment #3
Liam MorlandI haven't had a chance to investigate it. I did want to open an issue in case others were having this problem.
Comment #4
Liam MorlandOur Drupal cluster has two web servers. The problem is that Webform puts a file in the Drupal tmp directory, which is specific to each of the two web servers. When the page refreshes through the batch mechanism, if it goes through a different web server from the one it started on, the file is not there, so it errors out. The Drupal tmp directory needs to be shared between the servers.
We could have diagnosed this faster if there was no error suppression on the fopen() call. It seems to me that if the errors are suppressed, Webform should be checking if fopen() succeeded and generating its own errors if it did not. If there is no error checking, then fopen() errors should be exposed. I can write a patch to remove the "@" if you like.
Comment #5
quicksketchYeah that's a common requirement when working with shared servers.
I'm fine with removing the @. It's been there so long I can't recall what its purpose was. It probably was just to prevent errors from being spewed out all over the place to the end user in the event of a failure, but perhaps that the right thing to do (if you have errors reporting to the screen already).
Comment #6
Liam MorlandThis patch removes the error suppression from fopen().
Comment #7
quicksketchLet's put this in next pass through the queue.
Comment #8
quicksketchCommitted. Thanks again Liam!
Comment #11
fenstratNeeds porting to 8.x-4.x.
Comment #12
fenstratCommitted and pushed 9c7e97c to 8.x-4.x. Thanks!