Progress bar does not make progress

php.ini extra custom settings (extra information)
safe_mode = on
memory_limit = 128M
upload_max_filesize = 128M
post_max_size = 256M
extension=php_uploadprogress.dll

[uploadprogress]
uploadprogress.file.filename_template=

-------------------------------------------------

aditional info:
- the only field type file in the form
- created on "book" section
- upload works, but progressbar doesn't show any progress. tested with files over 70MB and 2MB...

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.

the problem is that the extension works perfect in linux, but not in windows+xampp 1.7.1 + drupal 6 . I checked doing my own upload form and it works, but in drupal does not work and return in json the value -1... also the reports shows properly that the extension is "working" and phpinfo shows that it works.... somebody can track this in windows + xampp 1.7.1 + drupal 6? actually the upload works, but the progressbar does not work...

Ok... i make the progressbar work.... but not for drupal :S, sometimes it make progress, and others not. sometimes it shows 5%:

{ "message": "Uploading... (4.3 MB of 79.63 MB)", "percentage": 5 }

and keep foreeeeeeeeeeeever until the file uploads properly.

configuration required:
1. xampp 1.7.1 for windows
2. php_uploadprogress.dll from here: http://downloads.php.net/pierre/php_uploadprogress-1.0.0-5.2-Win32-VC6-x...
3: php.ini:
safe_mode = on
memory_limit = 128M
upload_max_filesize = 128M
post_max_size = 256M
extension=php_uploadprogress.dll

here is the solution for make it working with the uploadprogress example.

1. download the progressbar example from pecl:
http://cvs.php.net/viewvc.cgi/pecl/uploadprogress/examples/

2. change your php.ini
php.ini:
[uploadprogress]
uploadprogress.file.filename_template=c:\xampp\tmp\file_template_%s.tmp
uploadprogress.file.contents_template=c:\xampp\tmp\file_contents_%s.tmp
uploadprogress.get_contents = 0

Note : default values does not redirect the information properly.... so i changed to a real physical

3. upload a file
voila : in the example is CLEAR that it uploads and shows progress, but in DRUPAL ITS BUGGY!!!! the upload by itself works properly, but frequently it starts with
{ "message": "Starting upload...", "percentage": -1 }

and the next updates may be the same or

{ "message": "Uploading... (4.3 MB of 79.63 MB)", "percentage": 5 }

or

{ "message": "Starting upload...", "percentage": -1 }

Please fix the code...., really i get it and i need the progressbar working for windows....

Finally it worked, my server that is windows 2003 server + Xampp 1.7.1 worked without problems.

how to make it work in windows:

1. xampp 1.7.1 for windows
2. php_uploadprogress.dll from here: http://downloads.php.net/pierre/php_uploadprogress-1.0.0-5.2-Win32-VC6-x...
3: php.ini:
safe_mode = on
memory_limit = 128M
upload_max_filesize = 128M
post_max_size = 256M
extension=php_uploadprogress.dll

here is the solution for make it working with the uploadprogress example.

1. change your php.ini
php.ini:
[uploadprogress]
uploadprogress.file.filename_template=c:\xampp\tmp\file_template_%s.tmp
uploadprogress.file.contents_template=c:\xampp\tmp\file_contents_%s.tmp
uploadprogress.get_contents = 0

2. Do not expect that works in your develop machine, it is too fast, but for production purposes WORKS HARD ROCK!!!

i hope this can help to anyone wants a progress bar in their drupal filefield projects

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.

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

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, all the but the last-added field works.

Now let's try with pre-existing fields (several files already uploaded, so Remove each and this leave us with 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, or do each separately like: 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 say 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 (??)