Improve feedback on invalid image upload #308
No reviewers
Labels
No labels
Component: User interface
Component: Wymeditor
Help wanted
Level: Difficult
Level: Easy
Level: Moderate
Pagetype: Festival
Pagetype: Mailinglist
Pagetype: Peer reviewed article
Pagetype: Text
Privacy GDPR AVG
status: has conflicts
Status: Needs changes
Status: Needs discussion
Status: Needs review
Status: Ready to merge
Status: Waiting for response
Type: Bug
Type: Enhancement
Type: Question
Usecase: De Stadsbron
Usecase: Koppelting
Usecase: MeetjeStad
Value: Coders
Value: Security
Value: Users
Value: Visitors
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
harmen/hypha!308
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Issue/234-Uploading-invalid-image-does-not-show-error"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Looks good at first glance. However, I do wonder: Where does the upload form get handled normally? Isn't there some error handling there already?
I believe that the upload plugin we're using now is (mostly) unmodified from the wymeditor version, we just plugged in a custom backend to handle the uploads. So maybe there is already working error handling, and a better (but not more complicated) fix would be to change the backend to return errors in a way the frontend code expects?
this gets passed
nullwhile it seems to expect an array. Will need to look further to see why it ends up with null here and not with backend response<script>...uploadReponse('~error')...This is the response on a good upload:
That comes from
I can replace the script with json but I haven't found the attribute to indicate an error (perhaps through http statuscode? (How can I make hypha return a 500?)
I suspect it gets passed null, because the string is invalid json (and jquery is told to expect JSON).
That looks like returning the error message in JSON is actually a good idea, then the success and error response are both JSON which is nice and consistent. However, it does seem that the original plugin code has no way to handle errors, which is a bit sad...
So, I would suggest we just add the error handling (probably just with an alert as before) in the image upload plugin, e.g. in here. It would be elegant to use a HTTP status code and have some kind of error handler, but it actually seems that the "iframe post form plugin" does not really support this (not sure if it could, using this iframe approach). So, just returning json with an
errrorfield and a message, check for that, and do an alert iferroris present is probably a clean approach?(I am wondering if we could maybe ditch the entire "iframe" approach somehow with newer web APIs or jquery plugins, but maybe we should not make this bigger than needed for now...)
Done :-)
Can we now also remove the ~ in front of the error messages or is that this used someplace else?
I'm very much in favor of baby steps ;-) Though I fully share the view that lossing the iframe would be a good thing :-)
Yeah, looks good!
Yes, let's just do that right away. I have not checked, but I suspect these strings are not used elsewhere (but that would be easy to check).
@ -357,11 +357,9 @@ EOF;}}}This could run into problems with escaping (e.g. when there is a
"in$response). I would suggest:And then let the existing
json_encodehandle (dropping the if before it).There is some additional refactoring that could maybe be done here, but some of this code might be replaced by Laurens' backend changes anyway.
On error, you now do
and on success
Those look like they might be doing the same, so maybe this can be one line outside of the if? Of is there a difference?
Ah, missed that one, dragging stuff around. Thanks!
@ -357,11 +357,9 @@ EOF;}}}Will do :)
PR looks better now. I still left some minor nitpicks inline, but I'll go ahead and just fix them in a minute myself.
This seems to add a newline for no apparent reason? I guess this part of the diff could be removed.
Hmm, seems my comment here got lost. The problem was (and still is) that the indentation is wrong here. I suspect some tabs vs spaces setting in your editor. The same happens elsewhere as well.
I think this extra id is no longer needed.
Looking at the file contents, the original file uses tabs for indentation, but your inserted lines use 4 spaces. Might be good to fix in your editor.
Fixed.
Fixed.
Fixed.
I fixed the issues I pointed out, squashed everything into one commit with a longer commit message (also adding a reference to the issue being fixed to allow auto-closing it) and rebased on top of master. I think this can be merged as-is now. Maybe @RoukePouw or @laurensmartina want to give this one last double-check?
Double checked, looks good! Thanks for the final fixes!
I fixed one more minor whitespace issue in the javascript, I'll merge this now.