Wrong order in initialPreviewConfig

[koxu1996]

Finally I figured out the problem with sorting. I setted uploadAsync: true. When you upload images for eg. 1.png, 2.png, 3.png, then upload is running in alphabetical order, but initialPreviewConfig not always will be ["1.png", "2.png", "2.png"], because it depends on responses end time:

In this case I got ["1.png", "3.png", "2.png"], but in preview I saw images in alphabetical order. So after switching first image (1.png in preview) with second (2.png in preview), the initialPreviewConfig is ["3.png", "1.png", "2.png"], but should be ["2.png", "3.png", "1.png"].

Tomorrow I will provide video which simply show this issue.

[kartik-v]

Yes you must not overwrite the initialPreviewConfig blindly after upload for your case and when using async uploads (uploadAsync is true).

For that scenario above you must return initialPreview and initialPreviewConfig directly as a JSON response in the upload server action as mentioned in ajax demo example # 6 which will return a preview specific only to the file uploaded.

[koxu1996]

@kartik-v No offence, but I use your plugin for a long time and I know how to use it correctly. Of course I am returning initialPreview and initialPreviewConfig. Lets add filesorted event to see what images are switched:

function(event, params) {
    alert('Switched ' + params.stack[params.newIndex].key + 
    ' from index ' + params.oldIndex + ' to index ' + params.newIndex);
}

When sometimes initalPreviewConfig is in nonalphabetical order and we move for eg. 2.png, then we see in alert that we switched 3.png! You can watch this bug on video.

[kartik-v]

@koxu1996 I see. The issue is not with initialPreview showing incorrectly. But it is more to do specifically with a very specific and special configuration for your use case:

1. you want to actually sort files in the preview
2. but with uploadAsync set to true
3. but you are returning initialPreview immediately after upload and want sort to sort thumbnails immediately even when other files have not yet been uploaded and the thumbnails are not yet returned from server.

So the issue is with no. 3 point above is. Since it uses the sortable plugin to drag sort... the plugin will only return the begin target and end target. and the files that are not uploaded yet will not be understood by the third party sortable plugin. Note that drag and drop using sortable is only enabled for initialPreview thumbnails and not the thumbnails which are yet to be uploaded.

It is thus recommended to NOT use uploadAsync specifically for the use case if you want to sort - because the file stack will not have the right data to display.

The recommended options if you want to drag and sort the thumbnails in the preview are:

• OPTION 1: Use with uploadAsync set to false and the rest of your configuration the same (including sending initialPreview immediately after upload). In that case the entire initialPreview will be directly rendered and understood by the sortable plugin.
• OPTION 2: Use with uploadAsync set to true BUT do not return the initialPreview immediately after upload. This will then show the thumbnails uploaded but will not allow drag and drop sorting. You can show initialPreview rather on page refresh where the sorting will work correctly.

[kartik-v]

There is a bit of enhancement I think I can include to prevent sorting when uploadAsync is true until all files are uploaded. Will update.

[koxu1996]

What about fixing order in initialPreview? It will allow to sort correctly with async: true

[koxu1996]

You don't understand me. I am talking about situation when all images are uploaded.
Your enhacement is not related with this issue.

[kartik-v]

Checking and will update... can you paste the code snippet that reflects the plugin configuration for your use case?

[koxu1996]

$("#w0").fileinput({
    'uploadUrl': '/image/upload',
    'async': true,
});
$('#w0').on('filesorted', function(event) {
    function(event, params) {
        //parms.stack[params.newIndex] is image which we moved
        alert('Moved ' + params.stack[params.newIndex].key + ' from index ' + params.oldIndex + ' to index ' + params.newIndex);
        }
});

You can see on video (0:24 and 0:44) that when I moved 2.png, I got alert Switched 3.png ... It is caused because wrong order in initalPreviewConfig.

But when initalPreviewConfig after upload was ["1.png","2.png","3.png"] (1:08 on video), then moving 2.png resulted with correct alert Switched 2.png ...

Currently initalPreviewConfig depends on response's end time and not always earlier started request is finished earlier. That is the problem.

[kartik-v]

Fixed and enhanced better.

It also includes a better way to prevent sortable to be activated when the uploads are in process. A complex use case for you to try is to set an initialPreview on page load... and then also try these async uploads that return initialPreview from server response (when uploadAsync is true).

[koxu1996]

Almost perfect, but one problem remains. You removed enhancement for #828 which allowed to sort images uploaded by clicking upload icons. Can you restore it and make working along with 0aab773?

[kartik-v]

The sort after single file upload still exists.

But for batch async uploads, yes as mentioned as per my comments earlier here and here... this is an intentional change. Now, if you click batch upload with uploadAsync as true, the sorting cannot be done now until all files are uploaded. This to ensure consistent sortable behavior and expected initialPreview.

Else you will have issues if you have 10 files being uploaded and say the 4th, 5th, and 8th files are not yet uploaded ... and if someone sorts it when these are in progress, the sorting order will change the initialPreviewConfig in an undesired manner (this is because the 4th, 5th, and 8th files cannot be dragged around - the order will surely be messed up).

Hence the fix ensures, the sorting can be done only after all files are uploaded.

[Minotti]

@koxu1996 this problem has been solved?

I am experiencing the same problem.

[koxu1996]

@Minotti There were a few bugs, but the problem was solved few years ago - not sure if it still works.

[Minotti]

@koxu1996 I suspect it has been resolved in the past and is now not working again.