According to admin/reports/status upload progress is not enabled because "Your server is not capable of displaying file upload progress. File upload progress requires PHP be run with mod_php and not as FastCGI." however I'm using Apache 2 and libphp5.so (which is, in fact, the new mod_php).
I'm not a php programmer, but some grepping for that sentence in D7 files followed by a check of phpinfo tells me that the problem is on lines 58 and 59 of modules/file/file.install within function file_requirements.
$apache = strpos($_SERVER['SERVER_SOFTWARE'], 'Apache') !== FALSE;
$fastcgi = strpos($_SERVER['SERVER_SOFTWARE'], 'mod_fastcgi') !== FALSE || strpos($_SERVER["SERVER_SOFTWARE"], 'mod_fcgi') !== FALSE;It seems to me that the code is trying to verify that the server is apache and php is not run with cgi by looking into the SERVER_SOFTWARE environment variable. I do have fcgi enabled as well as libphp5.so. Here's my SERVER_SOFTWARE variable value according to phpinfo:
Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 PHP/5.3.2 mod_fastcgi/2.4.2
Both PHP and fcgi are reported. Which is correct as they are both enabled.
A little googling around seems to suggest that PHP_SAPI or php_sapi_name() should be used for those tests.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | file_requirements-959060-1.patch | 843 bytes | AnalogFile |
Comments
Comment #1
AnalogFile commentedIn my case PHP_SAPI is "apache2handler", indicating both that it's apache and that it's not fcgi.
I do not know if other versions of the module report something else.
OTOH I think D7 requires php 5.2 which means the only other possible case is probably libphp5.so with Apache 1.3 (and libphp5.dll under windows with both versions of apache).
Since I do not know php I'm not going to touch the apache test nor I'm going to rename the variable to "mod_php" and invert the logic: I'm proposing the "minimal change" in this patch.
Comment #2
gpk commentedSince PHP 5.3, APC works well with PHP running as CGI (https://bugs.php.net/bug.php?id=57825). Does anyone know if APC's upload progress works in this config? (Certainly it used not to but that might be fixed now with PHP 5.3. http://www.php.net/manual/en/apc.configuration.php#ini.apc.rfc1867 makes no mention; and the mention here http://uk3.php.net/manual/en/function.apc-fetch.php#79321 of it *not* working dates back to 2007/PHP 5.2.)
Apols for slightly hijacking this thread but FastCGI (with APC) seems to be an increasingly common way of running PHP on shared hosts.
Comment #3
damien tournoud commented@gpk: APC has always worked with FastCGI. Bug #57825 was about making it work when FastCGI processes are launched independently one another. This configuration is *not* supported, and the bug has been closed without resolution.
As far as I know, upload progress on top of FastCGI requires a multiplexed FastCGI server implementation. Last time I checked, it was not possible on any of the major web servers (at least Apache, Nginx, LigHTTPd).
Comment #4
gpk commented@Damien Tournoud: thanks for the clarification!
Comment #5
gpk commentedUpdate: in cases where neither PECL uploadprogress nor APC can be got to behave (typically when using FastCGI), http://drupal.org/project/jquery_file_upload looks promising though doesn't support file field yet.
Comment #6
wmnnd commentedHello there,
I have created a little module that should remedy this problem by using JavaScript for determining the progress instead of a server-side solution. It works perfectly fine with all fields that support the default Drupal progress bar.
If you like, you can try and review it here: https://www.drupal.org/node/2402147
Comment #7
woodbutcher commentedI am getting an erroneous status report on my D7 site:
<<
Upload progress Not enabled
Your server is not capable of displaying file upload progress. File upload progress requires an Apache server running PHP with mod_php.
>>
It is working however, and phpinfo reports mod_php5 and uploadprogress enabled.
I am migrating a site from D6 to D7, both accounts on the same VPS, and the D6 site does not misreport in this way. Server is Centos with Apache 2.2.22, PHP 5.3.10 with DSO and SuExec enabled
So all is working as it should, just giving a heads up in case anyone else spends hours trying to fix this when it isn't broken.