Gallery submission data not retained upon error

[SpeedyD]

Bug as reported:

(Develop branch, last commit parent: b634616d8a0d2a2981f3f6dc123a696d7055c6d2 [b634616d])

URL of page: <siteurl>/gallery/submit/<gallery_no>
Description of bug: If there is even the slightest mistake made on a gallery submission, every bit of information is removed upon page load, except for the error.
How was the bug caused (exact steps to reproduce):
Considering this happens on literally every gallery submission with even the slightest mistake, you can easily reproduce this by filling in everything except the image upload and text block, It will erase every bit of information, except for the error.

Further details

Upon any error exception, a gallery submission is effectively returned empty, only displaying the error. Image data is gone, description is gone, content warning, added characters, collaborators, other participants and also the currency award form's information.

This may seem like a minor setback to most, but considering that in the currency form it is hard to tell what is optional and what is mandatory and that the maximum file size for images is actually LESS than 3 MB despite that the default text says it is (the size in app\Models\Gallery\GallerySubmission.php limits it to 3000 kB, which is actually approx. 2.86 MB), it is very much possible that the submission errors out more often than it should.

I've experienced frustrating setbacks myself on that end, and as I've heard similar complaints from other users, I know I'm not alone in this.

My suggestion here is therefore twofold: The simplest of the two is to, in app\Models\Gallery\GallerySubmission.php, change the validation rules of the image to have a default max of 3072, so that the default text doesn't lie..

And the more difficult of the two: re-populate the input after an error occurs. I'm aware that's much easier said than done, but it is a huge hurdle and source of frustration to many.

[itinerare]

1. The currency reward form is actively intended to be configured to suit your needs, including labeling; the default is presented largely as an example.
2. You are welcome to make a PR to adjust the particulars of the model if you so desire.
3. Does hitting the back button not return the form to its prior state? Certain things such as clone forms etc may not be repopulated given that they are dependent upon JS but the core elements should remain.

[SpeedyD]

Honestly, I'm not surprised that this is the response for points 1 and 2.. I might do point 2 for the Model, considering changing the number is a minor thing.. Point 1 is a bit of a broader issue, however, since it's not very easy to configure properly. I should make some time soon to go more in-depth on it.. But that's not the point of this issue report.

As for point 3: That doesn't work, no. The page is reloaded, so the previous page is not the submission. Hitting the back button therefore returns to the gallery- or whatever other page was the last. (Considering I've been going into the submission page multiple times today, I could technically go there straight with the URL after all..)

I have done further testing since opening this issue, and it seems that sometimes the description does stay, and sometimes it doesn't. I'm not sure what the difference is. I'm gonna try tomorrow or so if I can figure out what the difference is, and especially why some parts do or don't stay..

[itinerare]

Re 1, I'm not sure what you mean... The config file (as well as the attendant function which does the calculating) is commented fairly thoroughly explaining its contents; assuming the minimal case in which you only wish to clearly label required sections, this would be rather straightforward as each field has a dedicated 'label' value which can be freely adjusted in the config file. But I digress.

Hmm, alright. At minimum the expectation would be that the title and description would stay, as would other fields that are present on page load (that is, aren't cloned/produced via JS). Unsure why only some elements would stay within those constraints though. This also points to the notable wrinkle of this issue... theoretically content in any form present on page load should readily stay, or be made to do so, but any proposed solution to this particular issue needs to be able to reproduce the content of any clone forms.

[SpeedyD]

Sidequestion cause I'm partially wondering- if I'm understanding the code correctly, $data exists on the reload regardless, so.. couldn't we code in something that re-populates even the JS cloned/produced inputs using what's in $data? Something that waits for page to load.. probably part of the script block itself?

Might be a bit of trouble, but could solve a few issues. The only real problem I can foresee is the currency form being customizable..

[preimpression]

Potentially useful for this issue
https://stackoverflow.com/questions/31081644/how-to-redirect-back-to-form-with-input-laravel-5