Upload usability fixes

[petschki]

Closes #1491
Successor of #1492

This PR implements:

1. A new pattern option upload-add-immediately which defaults to true. This fixes usability issues in the TinyMCE link/image modal.
2. Button label changes to "Select or Upload" when upload is activated
3. Do not close upload column when uploading a file fails
4. minor tinymce pattern cleanup because of removed "upload" tab in modal

[erral]

I tested the inmediately-add-and-select feature and works as expected.

I tested also the upload fails, and the error is shown in the dialog, so I would say that is expected too.

[erral]

The only thing I found is that the Image browser lets you uploading an arbitrary PDF file which then is inserted in TinyMCE which it shouldn't be possible.

[petschki]

The only thing I found is that the Image browser lets uploading an arbitrary PDF file which then is inserted in TinyMCE which it shouldn't be possible.

Yeah, saw that too. Dropzone.js has an option acceptedFiles which we can narrow down to image/* mimetype for only accepting image types. But ideally this is configurable on our side too ... maybe uploadAcceptedMimeTypes or something like that. Then the tinymce pattern can set this when firing up the ImageModal ... since I have all files open, I'll check that now 😉

[petschki]

@erral mimetype restriction argument is implemented and image modal now only allows "image/*" mimetype. The only thing I encountered is when dropping a disallowed mimetype to the dropzone ... this should be more obvious that the dropped file is not allowed... selecting with "browse" is OK, because the file brower is restricted to the mimetype.

[erral]

@erral mimetype restriction argument is implemented and image modal now only allows "image/*" mimetype. The only thing I encountered is when dropping a disallowed mimetype to the dropzone ... this should be more obvious that the dropped file is not allowed... selecting with "browse" is OK, because the file brower is restricted to the mimetype.

Yes I have seen that too :)

But I think it is working.

[erral]

@petschki do you want me to further test this? I see some changes after my previous tests...

[petschki]

Currently I'm waiting for @frapell feedback but I think you have tested the uploadAcceptedMimetypes parameter already, did you? That was the last change ...

[erral]

Currently I'm waiting for @frapell feedback but I think you have tested the uploadAcceptedMimetypes parameter already, did you? That was the last change ...

Mmmm, I tried passing a custom mimetype in that option (adding {"uploadAcceptedMimetypes": ["image/jpg"]} in patternoptions, right?) but I can't make it work.

Perhaps I am missing something, I will keep testing it.

[petschki]

This has to be a string (like "image/*,application/pdf") ... see dropzone options for details: https://github.com/dropzone/dropzone/blob/main/src/options.js#L203

Basically like here https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file#accept

[erral]

This has to be a string (like "image/*,application/pdf") ... see dropzone options for details: https://github.com/dropzone/dropzone/blob/main/src/options.js#L203

Basically like here https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file#accept

Ah, of course :)

It works as expected, but the behavior is a bit strange if I use the options like "doc" explained in the MDN docs, but setting full mimetypes works as expected.

Like previously, I can cheat my browser and select a non-accepted mimetype file, and it tries to upload but it finally doesnt' and doesn't report the error.

I could live with that, but if possible it would be nice to report an error there.

[frapell]

@petschki As far as I can test, this seems to be working perfectly, and I see the error printed if the @@fileUpload view fails.

I would focus in errors reported by normal usage by editors, and while it would be nice to show error messages in cases like the ones mentioned by @erral I think it is fine if someone manages to "cheat the browser" to not actually get a helpful error (In fact if they are messing with the devtools, they might know already what the error is about ;) )

[frapell]

LGTM !

[erral]

I am merging the locales PR too.

[petschki]

This (and others) is now released in plone.staticresources = 2.3.4 ... see https://github.com/plone/mockup/releases/tag/5.4.5