Attempting the following command:

drush wfx --file=./test.xlsx --format=excel --batch-size=1000 44

...I get the following output:

Exported 1000 of 10852 submissions...                                [ok]
Exported 2000 of 10852 submissions...                                [ok]
Exported 3000 of 10852 submissions...                                [ok]
Exported 4000 of 10852 submissions...                                [ok]
Exported 5000 of 10852 submissions...                                [ok]
Exported 6000 of 10852 submissions...                                [ok]
Exported 7000 of 10852 submissions...                                [ok]
Exported 8000 of 10852 submissions...                                [ok]
Exported 9000 of 10852 submissions...                                [ok]
Exported 10000 of 10852 submissions...                               [ok]
Exported 10852 of 10852 submissions...                               [ok]
ZipArchive::open(): Empty string as source                           [warning]
webform_exporter_excel_xlsx.inc:150
Export creation complete. Your download should begin now. If it does [status]
not start, download the file here. This file may only be downloaded
once.

It all seems to be going well, but as one might imagine with that ZipArchive error, there's no actual output file at the end of the process. I thought it might be the problem described here:

https://www.drupal.org/node/2443373

...but that fix appears to be in 7.x-4.9.

Any suggestions? Thanks!

Comments

DanChadwick’s picture

DanChadwick CreditAttribution: DanChadwick commented

What happens if you do the same thing through the UI?

I'm afraid you're going to have to debug this.

wrd’s picture

wrd CreditAttribution: wrd commented

Well, the problem isn't quite what I thought. The file is written out, it just isn't written at ./test.xlsx. (I'm not sure where it DID go, but if I specify a full path like /home/mydir/test.xlsx, I get the file.)

However, Excel (2007) doesn't like the file, saying it may be corrupted. If that may be caused by the "empty string" error while generating the file, we may as well continue here.

I'll go ahead and attempt a UI export. Thanks for the reply!

DanChadwick’s picture

DanChadwick CreditAttribution: DanChadwick commented
Status: Active » Fixed

I'm not sure there's still an issue here. If you can open the file in something else (like open office) and can figure out what Excel doesn't like, that's great. But with that many submissions, it may be very hard to figure out. My guess is some character that Excel doesn't like.

wrd’s picture

wrd CreditAttribution: wrd commented
Status: Fixed » Active

The export works just fine from the UI, with all default options apart from selecting Excel format. Excel is able to open the file without error. Not sure why it would behave differently when run from Drush. If you don't feel there's an issue remaining with this added info, feel free to close; I'll see if I can get them to accept the CSV output. Thanks again!

DanChadwick’s picture

DanChadwick CreditAttribution: DanChadwick commented

Excel files are just zip archives. Add '.zip' to the end and extract the file. Then compare the drush exported file with the UI exported file using diff or git diff. That will tell us what differences there are between the two ways of exporting the file.

wrd’s picture

wrd CreditAttribution: wrd commented

Thank you, this is becoming more clear.

The failure appears to be happening when Drush attempts to zip the file. What I'm winding up with is just an XML file that matches the "sheet1" XML file within the UI download. Byte count matches exactly, and diff shows both XML files to be identical.

So it looks as if both methods are generating the same data -- Drush just isn't successfully packing that file up into the .xlsx bundle.

DanChadwick’s picture

DanChadwick CreditAttribution: DanChadwick commented

Drush runs with a different php. The UI will run through mod_php, whereas drush runs with the CLI PHP. I'm thinking that your CLI doesn't have the PHP zip functions compiled or enabled.

wrd’s picture

wrd CreditAttribution: wrd commented

php -i shows:

Zip => enabled
Extension Version => $Id: 05dd1ecc211075107543b0ef8cee488dd229fccf $
Zip version => 1.11.0
Libzip version => 0.10.1

Additionally, I tested the first zip example shown here:
http://php.net/manual/en/zip.examples.php

...and it successfully generated a working zip file when run from the command line. So the zip functions do seem to be working in general.

I tried turning up the verbosity in my drush config file, but it didn't generate any additional output either shortly before or after the error.

DanChadwick’s picture

DanChadwick CreditAttribution: DanChadwick commented
Status: Active » Closed (cannot reproduce)

A permission issue, perhaps?

Well something in your configuration is keeping drush from being able to make the archive. I think you'll (or your developer) will have to debug the drush command in webform to see what's happening. I'm out of ideas. Given the number of webform installations, I'm guessing that more than a few people are using the wfx command without issue.

wrd’s picture

wrd CreditAttribution: wrd commented
Status: Closed (cannot reproduce) » Fixed

Problem solved. I don't know if this'll ever help anyone else, but in case it does:

Your suggestion that it might be a permissions issue sent me on a search for any file paths it might be using. Adding some drush_log() statements to the exporter, I discovered that line 147:

$zip_filepath = drupal_realpath($zip_uri);

...was returning null. Turned out this was due to some conditionals that set some variables based on the hosting environment; drush wasn't catching the fact that it was running on the test server, and was trying to use a temp directory for a different environment. Never was a problem before, because until recently I only had drush on my local.

Once that was corrected so that drush knew where it was running, it was able to find the correct temp directory and build the .xlsx file properly.

Thanks again for your time and your help.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.