Closed (cannot reproduce)
Project:
Download Count
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
17 May 2011 at 19:47 UTC
Updated:
1 Aug 2013 at 20:50 UTC
If I am viewing the Download Count page (/download_count) and then I click Export for one of the files, I will be redirected to a page (such as: /download_count/20856/export) with options.
No matter what I choose - or if I leave it blank - and click "Export" I get a helpful Drupal message "blahblahblah.csv has been successfully exported." but .. no file. Where was it exported to? Is it maybe explained somewhere that I haven't seen?
Thanks!
Comments
Comment #1
WorldFallz commentedThat depends on where your browser is setup to download files to. Did you search the hard drive?
Comment #2
Offlein commentedHaha, no no, it didn't download in the browser, unless you've found a way to download files to the user's hard drive without notifying the user at all.
It's a Drupal message, like a drupal_set_message() message. And no popup or download actually occurs.
Comment #3
WorldFallz commentedwith firefox, the download can occur with a quick message in the status bar only (no popup)-- easily missed. Did you actually search the hard drive? I can't seem to reproduce this.
Comment #4
Offlein commentedNope, not that. I just checked on a different server and, guess what, works okay. Your thing looks like it writes a file first and then opens/sends that? I think the file may not be successfully written on my production server's temp dir or something. Looking deeper.
Comment #5
Offlein commentedSo the headers look very different on the two servers, which is to be expected, but I don't know if there's something clearly on the non-working one that's not getting set right. I'm running it by my server people (that is, Acquia) as well.
Here's what I get in terms of headers on my working server:
And here on the non-working (our production) server:
Comment #6
webkenny commentedWe have discovered the problem. The PHP
flush()command does not work with mod_fcgid + PHP fcgi in the default configuration. TheOutputBufferSize, as suggested by http://permalink.gmane.org/gmane.comp.web.fastcgi.fcgid.user/322, needs to be set to an appropriate number.The choice is on the user to either change this setting if their hosting provider allows it (most do not) or Download Count should find a different method to deliver the file. Possibly writing the file to Drupal's temporary directory and then delivering it.
IMO, the latter is the more compatible option.
Comment #7
WorldFallz commentedThanks webkenny for tracking down this issue. I lost quite a bite of time trying to replicate it and never did have any success.
And I agree with your 2nd option of saving a temp file. Not sure when i'll be able to carve out the time for a patch, but I'll update this issue with progress.
Comment #8
Spechal commented+1
Fixed my issues by setting FcgidOutputBufferSize 0 and putting ob_flush() before flush() on Apache 2.2.22, mod_fcgid 2.3.7 and PHP 5.3.16
Comment #9
WorldFallz commentedcleaning the issue queue. This will have to wait unless someone provides a patch.
Comment #10
WorldFallz commentedi would think this applies to both versions, and would be fixed for d7 then backported for d6.
Comment #11
WorldFallz commenteddoesn't look like any more info is forthcoming on this one. closed for lack of activity.