Currently the system uses either: PECL uploadprogress http://pecl.php.net/package/uploadprogress or APC rfc1867 to show file upload progress (neither of which work with PHP 7 and nginx).

There was a discussion here https://www.drupal.org/node/1561866 about using the built in php session upload progress (PHP 5.4+) however Drupal's implementation of PHP session seems to interfere with this in a lot of cases.

https://www.drupal.org/u/droplet suggested that as D8 uses the jQuery.form plugin, it's proposed that we remove the reliance on 3rd party PHP libraries in the built in session upload progress and go with a the jQuery.form client side solution.

I have attached a patch that implements this and removes the old solutions.

It definitely needs review and some additional work (I would like this to work with remote file systems and CORS upload eventually).

Tested with Apache2 and nginx in Chrome (latest version).
I suspect there may be issues with Internet Explorer 9 compatibility. Does anyone know if there is a fallback built into jQuery.form to handle this?

Comments

rjjakes created an issue. See original summary.

rjjakes’s picture

Status: Needs review » Needs work

The last submitted patch, 2: core-jquery.form_upload_progress-2833968-2-8.3.x.patch, failed testing.

andypost’s picture

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?

rjjakes’s picture

Hi @andypost, I'll do the test fix later today when I get chance.

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?)

droplet’s picture

Thanks @rjjakes !

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

+++ 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..

droplet’s picture

rjjakes’s picture

@droplet - I made the call back to the fileprogress endpoint (core/modules/file/src/Controller/FileWidgetAjaxController.php in this case) with additional data to keep as much of the existing code in place as possible. Are you saying I should drop this in favour of a purely client side solution? If so, this is significantly more refactoring and has the potential to break the batch progress too.
I think we should keep it as is (calling back via AJAX to core/modules/file/src/Controller/FileWidgetAjaxController.php) to maintain consistency.

rjjakes’s picture

rjjakes’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 9: core-jquery.form_upload_progress-2833968-9-8.3.x.patch, failed testing.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.