Upload progress using jQuery.form plugin instead of 3rd party PHP libraries

Looks great, only fix tests left and approval about backward compatibility

+++ b/core/modules/file/file.install
@@ -63,60 +63,11 @@ function file_schema() {
       'title' => t('Upload progress'),
...
+      'value' => t('jQuery.form uploadProgress'),
+      'description' => t('Drupal 8 uses client side jQuery.form uploadProgress. No extensions are required.'),

not clear is this this needed?
maybe some setting still can block that?

Thanks @rjjakes !

We can keep current PHP code as BC layer. (Until we have a final decision: #2390621: [policy, no patch] Update Drupal's browser support policy)

+++ b/core/modules/file/src/Controller/FileWidgetAjaxController.php
@@ -24,20 +24,9 @@ public function progress($key) {
+    if (isset($_GET['loaded']) && isset($_GET['total']))  {
+      $progress['message'] = t('Uploading... (@current of @total)', array('@current' => format_size($_GET['loaded']), '@total' => format_size($_GET['total'])));
+      $progress['percentage'] = round(100 * $_GET['loaded'] / $_GET['total']);
     }

It's 100% client-side. We can drop it I think.

I wasn't sure if we should keep the entry on the status page either. Perhaps it would be useful as an indicator that things have change (then we can plan to remove it completely for a much later release?)

Might be we only tell it doesn't work in older IE & browser do not support ProgressEvent..

Hello rjjakes,

Thank you, after patched by hand 3 files on D8.3.7 , It is working good :-)

xxx@xxxxx:/home/sites/drupal8⟫ patch -p1 < sites/PATCHS/core-jquery.form_upload_progress-2833968-9-8.3.x.patch
patching file core/misc/ajax.js
patching file core/misc/progress.js
patching file core/modules/file/file.install
Hunk #1 FAILED at 63.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/file/file.install.rej
patching file core/modules/file/file.module
Hunk #1 FAILED at 913.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/file/file.module.rej
patching file core/modules/file/src/Controller/FileWidgetAjaxController.php
Hunk #1 FAILED at 24.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/file/src/Controller/FileWidgetAjaxController.php.rej
patching file core/modules/file/src/Element/ManagedFile.php

Here is the patch for D8.3.7

Rerolled the patch in #15 for 8.6.x; it also applies to 8.5.3.

Fixing coding standards.

We've ported this implementation over to Backdrop in https://github.com/backdrop/backdrop-issues/issues/3211.

+  Drupal.Ajax.prototype.uploadProgress = function (event, position, total, percentComplete) {
+    this.progress.object.setProgressdata({
+      loaded: position,
+      total: total
+    });
+  };

I don't think there's any need for the new `setProgressdata()` method or to call it here. The progress object already has a `setProgress()` method that could just move the progress bar.

The Backdrop implementation also takes @_nod's suggestion and just switches the implementation to be entirely client-side. If you'd like to continue supporting old browsers, Backdrop lets uploadprogress or APC (if available) take precedence, but honestly the client-side only implementation is better all around. Browser support is very good at this point: https://caniuse.com/#feat=xhr2

To keep this going, here's a reroll of the patch in #19 against 8.7.x. Also applies against 8.6.x.

As suggested in #22, this patch uses setProgress() to move the progress bar instead of a newly added setProgressdata() method.

Getting an error when the file upload is set to throbber rather than progress bar.

Oops uploaded the wrong patch.

Hello,
the patch applies well, the progress bar is also displayed, but it remains motionless at the beginning without growing until the end of the file upload (I forgot to empty the cache) ...
If I go back to the network tab of the dev tools, I have progress requests that go well,

https://xxxxxxxxxx.com/file/progress/61023309?_format=json
https://xxxxxxxxxx.com/file/progress/61023309?_format=json
[...]

but the answer is always:
{"message": "Starting upload ...", "percentage": - 1}
it is as if the GET 'loaded' and 'total' variables were not sent or received.
But why always use the return json if the code uses the function "setProgress (percentage, message, label)" by now ?

I put a:
console.log ('percentage:' + percentage + ', message:' + message + ', label:' + label);
in the "setProgress" function and I have the following:

percentage:5 , message:undefined , label:undefined
percentage:-1 , message:Starting upload... , label:undefined
percentage:7 , message:undefined , label:undefined
percentage:9 , message:undefined , label:undefined
percentage:11 , message:undefined , label:undefined
percentage:13 , message:undefined , label:undefined
percentage:-1 , message:Starting upload... , label:undefined
percentage:15 , message:undefined , label:undefined
percentage:17 , message:undefined , label:undefined
percentage:19 , message:undefined , label:undefined
percentage:21 , message:undefined , label:undefined
percentage:-1 , message:Starting upload... , label:undefined
percentage:23 , message:undefined , label:undefined
percentage:26 , message:undefined , label:undefined
[...]
percentage:100 , message:undefined , label:undefined
percentage:-1 , message:Starting upload... , label:undefined

why, the ligne "percentage:-1 , message:Starting upload... , label:undefined" ?
why message never indicate "Uploading... (@current of @total)" ?

Hello again,
I modified the last patch to work at home on D8.7.2 (to display the message above the progress bar), it's probably not very good coding, but it works, do not hesitate to rot and make the changes you need ;-)

I removed too many things in my last patch and the progress bar for something other than images no longer function (update translation, etc.)
Here is the new one.

Thank you for your patch, it work great for upload using regular drupal forms, but not working when uploading file using file manager, any idea how to make it work in file manager too?

Rerolled for 8.8.

Hello,
The patch applies well, but on my side the progress bar remains glued to the left until the document has finished downloading ...

This patch works for me, by added "ajax.uploadProgress" inside the 2 js files...

Thanks Steve!
Whoops. @douggreen pointed out that the re-roll left a bit of cruft.

Review OK for me with patch 38 :-)

I noticed a PHP notice on the Status report, this patch should fix that.

Sadly no interdiffs in last patches...

+++ b/core/misc/ajax.es6.js
@@ -903,6 +906,27 @@
+        const sizes = ['Bytes', 'KB', 'MB', 'GB', 'TB']
...
+      $message = Drupal.t('Uploading... (@current of @total)', {'@current': bytesToSize(position), '@total': bytesToSize(total)});

Are you sure that TB is enough? The core's `format_size()` function provides 4 more and makes them translatable

Here's the interdiff between 38-41, it's small enough to not need a file.

diff --git a/core/modules/file/file.install b/core/modules/file/file.install
index aedf295686..4e8aa28ec4 100644
--- a/core/modules/file/file.install
+++ b/core/modules/file/file.install
@@ -67,6 +67,7 @@ function file_schema() {
 function file_requirements($phase) {
   return [
     'file_progress' => [
+      'title' => t('Upload progress'),
       'value' => t('jQuery.form uploadProgress'),
       'description' => t('Drupal 8 uses client side jQuery.form uploadProgress. No extensions are requried.'),
     ],

Tests did not pass

I'm wondering since we seem to be moving away from jQuery UI and maybe jQuery too, that we could use something like this:
https://htmldom.dev/upload-files-with-ajax/

Feel free to punt me to a new issue if that is diverging too far from this issues scope.

Patch #46 still works on D9.2.7 :-)

Just want to confirm... patch #46 works on 9.4.5.

I tried for months trying to get PECL uploadprogress package working on my server and drupal site. Never could. This patch was such a simple solution.

Would be great to get a new patch file that passes tests. And move forward on getting it into core.

It makes sense to ind replacement as core is getting rid of jquery

Patch update for D9.5.0

try to fix #60

New try to pass test...

There are always some mistakes :-(
But still, the patch works well for D9.5.0.
And for D10, the patch generated from the "merge request !3190" also works.
D10 patch : https://git.drupalcode.org/project/drupal/-/merge_requests/3190.patch

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

MR had a CI failure and still needs tests.
Hiding the files to avoid confusion.

This is a reroll of #62 for 11.x, which also applies to 10.1.x. I'm getting an error when trying to create an interdiff that I'm unable to figure out at the moment (interdiff fails to process the patch files for some reason). This patch a straight reroll of the patch in #62. The only change is that I omitted the Drupal version number in the changes to file_requirements(), and in the comment for file_progress_implementation().

Do we need the file_requirements() at all? There is no system information to display anymore on the status report, so we could remove that message.

Leaving as needs work for tests.

This is a re-roll of patch #67 works but gives an error since SystemManager's listRequirements method expects a title on the requirement and gives an error on 10.1.x.

Is this related to https://www.drupal.org/project/drupal/issues/1561866?

Patch #68 works for me on D10.1.6 😀

Fix Patch not apply for 11.x

Please include interdiffs with patches, also encouraged to start using MRs instead.

Seems this was tagged for tests which reroll didn't have

#68 doesn't apply to 10.2, and #71 applies to 10.2 but doesn't show progress correctly (bar just goes straight to 100%).

Here is a new working patch based on #68 for 10.2.