Progress bar does not make progress

This is probably a configuration problem on your server and not particularly a problem with the software. I assure you that the upload progress bar works when the PECL uploadprogress extension is working properly. First, make sure that "uploadprogress" is actually available by visiting a page containing <?php phpinfo() ?>, if it's not listed there, it's not working. Then visit your admin/reports/status page and check to see if FileField is reporting that upload progress is working.

I'm having the same issue Drupal 6.10 : The progress bar is there but displaying no progress at all .
I've checked :
The Drupal Status Report > Upload progress : "Enabled (PECL uploadprogress)"
My PHP settings : PHP Extension 20060613 ( that should mean that uploadprogress is installed propely...since the path of the extension was when I installed uploadprogress : .../extensions/no-debug-non-zts-20060613/)
So everything should be correctly installed .

Please help !!

Configuration :
Drupal 6.10
Web Server Apache/2.2.11 (Unix) PHP/5.2.9 mod_ssl/2.2.11 OpenSSL/0.9.8c mod_fastcgi/2.4.6 Phusion_Passenger/2.1.2 DAV/2 SVN/1.4.2
PHP 5.2.9
uploadprogress 1.0.1

Apparently the PECL uploadprogress extension does not work with PHP compiled as Fast CGI (hence why IIS and LightHTTPD do not work either), see http://pecl.php.net/bugs/bug.php?id=14400. Seems like something that should be checked for at least and sent to the user as a warning.

Thanks a lot ...looks like for the same reasons the APC extension won't make it also ...?

I've applied the attached patch which gives the correct status of the uploadprogress extension if running PHP as FastCGI. Because it looks like there's a technical limitation at the Apache level when using FastCGI (see PECL bug report link above), the best we can do is accurately report what the problem is.

I'm not sure what the done thing is here: reopen a bug if the solution is broken or open a new bug. To keep the number of bug reports to a minimum I have reopened this one. Please let me know if this is the wrong thing to do.

This patch is too strict. You can have FastCGI enabled in Apache and still be using mod_php. My status tells me:

Your server is not capable of displaying file upload progress. File upload progress requires PHP be run with mod_php and not as FastCGI.

but the progress bar works perfectly!

My Server: header looks like this:

Server: Apache/2.2.9 (Debian) mod_auth_pgsql/2.0.3 mod_fastcgi/2.4.6 PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0

If you're using FastCGI and you're not using mod_php, does the server string still include "PHP"? That is, should the condition double-check for PHP or mod_php if mod_fastcgi is found? Not sure...

Hmm, how odd. It does look like you're using FastCGI are you not? Or are you saying that you *have* FastCGI, but you're actually using mod_php? That's just confusing. ;-)

As far as I can tell, there is no information included at all if you're using mod_php. For example my $_SERVER_SOFTWARE is Apache/2.0.59 (Unix) PHP/5.2.5 DAV/2 mod_ssl/2.0.59 OpenSSL/0.9.7l. If there is a more reliable way of identifying which mechanism PHP is running under, I'd be happy to use that instead. As it is, I couldn't find any better indicator than the server software line, and while I'm aware it's *possible* to have both extensions installed, I don't think it's a common configuration since you usually only want one or the other. In this case, I think it's definitely better to warn that something will not work when it does, rather than indicating that it will work when it doesn't (which was the previous scenario).

I have FastCGI but am not using it for PHP. FastCGI might be used by other people on the server running Ruby or some other scripting language - we have about 80 virtual hosts, so it is hard to keep track of who uses what... ;-)

I think the PHP function that can be used here is php_sapi_name(). For me it returns "apache2handler". I wonder what it prints when running PHP under FastCGI?

According to http://forums.iis.net/t/1156701.aspx, php_sapi_name() will print cgi-fcgi when running under FastCGI.

I'd like to add that I've been watching this issue for a long while, and that I have a dedicated simple Drupal instance set aside just for tracking this issue.

I'm thankful that the author thinks it's a good idea to have a progress bar, as my site uploads many huge files (this is data for research, not questionable content) and the progress bar is very, very necessary.

I won't get into every single scenario, but I'll offer this simple repeatable one:

Edit a node that uses filefield. In this example let's say that there are already a number of files uploaded before we opened the node to the edit form. Let's also use files of size 30-90MB so we're sure it doesn't upload so fast that we'll miss a working progress bar altogether.

There should be an empty field. Browse to a file and upload it. Don't save the node.

Now let's use Add another item to add ONE additional field. Browse to a file and upload it. Notice that the progress bar works great.
Now let's use Add another item to add TWO additional fields. One at a time, browse to a file and upload it. Notice that the first field's progress bar doesn't work, but the 2nd field does work!
Now let's use Add another item to add THREE additional fields. By the same procedure, browse and upload each one at a time. Notice that the 1st and 2nd don't work but the last one does work.
So in this scenario, only the last-added field works.

Now let's try with pre-existing fields (several files already uploaded, so Remove each and this leaves several unpopulated fields). Remove all of the pre-uploaded files (either before saving the node from the last exercise or after saving and re-entering edit mode).
Either pre populate all the fields and then click the upload buttons in succession: Browse...browse...browse, Upload...upload...upload; or do each separately: Browse...Upload, Browse...Upload, etc. (try both). You'll see that all of the progress bars now work.

Now let's see what happens when we have four (4) fields already uploaded, we Remove the files in each of them (but don't save the node or upload any files just yet!), then add two (2) more via Add-another-item. We should now have six (6) unpopulated fields. You'll see that the progress bar works in only the very last one. (none of them work except the last of the newly added).

These tests were on Drupal 6.13 with CCK 6.x-2.5 and Fielfield 6.x-3.x-dev ($Id: filefield.module,v 1.208 2009/07/25 04:10:49), on Apache atop RHEL5 & PHP 5.2.6, using FirFox 3.0.13. And over many months I've seen some different behaviors, such as with my development site with different versions of CCK/FF and with additional modules. For example, at one point I was using Getid3 and uploading reasonably-sized files so that Getid3 could finish parsing the file for a mimetype before the next upload button was pressed. If I initiated a second upload too quickly then the bar would again not progress.

As for the "once fields are populated via 'Browse...', clicking 'Add another item' causes all fields to upload and none use progress bars" issue -- I worked around this by using my theme script.js to disable Save and Add-another-item until all populated fields are finished uploading.

If anyone is actively working on this then I'll be happy to try to help by testing, etc. At one point quicksketch thanked me for testing but I never heard any more about this, and it's still a mystery where the cause lies -- in CCK, uploadprogress, etc.

I hope this helps!

EDIT: I'm trying to track this down but haven't got very far. BUT I can say that Apache is responding to GETs by the browser (every 2 seconds):
GET - https://myserver.edu/filefield/progress/4bbf61de51de635355ed3eee549dd2b1
... and where it should be returning something like:
{ "message": "Uploading... (12.46 MB of 96.56 MB)", "percentage": 13 }
... it's instead returning:
{ "message": "Starting upload...", "percentage": -1 }
(The JSON tab (Firbug) also shows message: "Starting upload..." and percentage -1 instead of "Uploading... (12.46 MB of 96.56 MB)" / percentage 13)

So perhaps something is going wrong between Filefield and CCK's Add-another-item. Tho the browser seems to know a $key for each field when each Upload is clicked (visible in the GET via firebug), but perhaps it's being lost on the back end when Add-another is used so function filefield_progress() doesn't know what to do (??)

subscribing

Subscribing too ;)

subscribing

Let's consolidate this with #633862: No progress status in PECL upload progress bar.

Upload progress Not enabled
Your server is not capable of displaying file upload progress. File upload progress requires PHP be run with mod_php and not as FastCGI.

Apache/1.3.41 (Unix) PHP/5.2.4 mod_fastcgi/2.4.2 mod_perl/1.30 mod_jk/1.2.25 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a

--

Anyone know how you go about fixing this?

--

My php_info() says that I have php_mod5 installed, not sure if this is the same as php_mod.

"Loaded Modules: mod_php5, mod_fastcgi, mod_security, mod_perl, mod_jk, mod_log_bytes, mod_bwlimited, mod_frontpage, mod_ssl, mod_setenvif, mod_so, mod_unique_id, mod_headers, mod_expires, mod_proxy, mod_auth, mod_access, mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status, mod_negotiation, mod_mime, mod_log_config, mod_env, http_core"

Is it possible to change this around, overwrite the php.ini.

Im on a reseller package. And been meaning to fix this up, so all my clients can hopefully have this working in one hit.. Should I contact my hosting and ask for it to change?

having the same issue here. subscribing.

My hosting company uses suPHP, and uploadprogress.so is loaded by using a custom php.ini file. I have successfully tested that the upload progress does work under this configuration, but I am still receiving the following error message in the status page:

Upload progress Not enabled
Your server is not capable of displaying file upload progress. File upload progress requires PHP be run with mod_php and not as FastCGI.

This is because suPHP reports itself as FastCGI. The SERVER line indicates that it is FastCGI and so file field detects it as such, even though upload progress works perfectly. This is identical to the behavior described by Martin.Schwenke in post #11 above.

Furthermore, php_sapi_name() returns cgi-fcgi, so that can't be used either. I would recommend that this status message just be changed to a warning. I suggest the following wording:

Upload progress Possible issue
Your server indicates that it is running PHP via FastCGI, but upload progress requires that it be run as mod_php. If you know that your server is not actually running as FastCGI, but is just reporting as such, you may ignore this issue. Otherwise, please check that PHP is running as mod_php to ensure compatibility with upload progress.

I realize this is a bit long, and so my other suggestion (which would require more work) would be to change the status message as follows:

Upload progress Possible issue
We could not determine if your server is capable of running upload progress. Please run the manual test to determine upload progress compatibility.

Clicking "run the manual test" would then lead to a simple page which had a file upload field. The instructions could read something like "Please upload a large file (>32MB) to test the upload progress indicator. This file will be immediately deleted upon completion of the test." You can see where this is going. The user could then confirm that upload progress is working, or indicate that it did not work.

I have the same "non-issue" and my hosting company (HostGator, great 24/7 chat support, BTW) also uses suPHP.

So I guess something must be done either from suPHP (change identification) or Drupal 7 (properly recognize suPHP) at code level.

I installed drupal 7.

This is my problem 'Your server is not capable of displaying file upload progress. File upload progress requires an Apache server running PHP with mod_php.', and I can't add logo or any image to my appearance

This is information of my server
System Windows NT PORAR-INET-69 6.0 build 6002
Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--with-snapshot-template=d:\php-sdk\snap_5_2\vc6\x86\template" "--with-php-build=d:\php-sdk\snap_5_2\vc6\x86\php_build" "--disable-zts" "--disable-isapi" "--disable-nsapi" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared" "--without-pi3web"
Server API CGI/FastCGI
Virtual Directory Support disabled
Scan this dir for additional .ini files (none)
additional .ini files parsed (none)
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams php, file, data, http, ftp, compress.zlib, https, ftps, zip, compress.bzip2, public, temporary
Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls
Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.*, bzip2.*

What do I have to say to my server? Do I must to change Windows NT to Linux?

Please forgive me if my language is not well.

suPHP is to be blamed here, since CentOS with uploadprogress bar and FastCGI does not give such a report.