-
-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement suggested for blueprint's forms - make it possible to upload through "File" without saving the page #792
Comments
@w00fz can provide a better answer than I as he just refactored this field. |
I know this doesn't fully answer your question but this is when the change occurred and part of the reasons it did: #748 The main reason for not automatically storing files upon upload is to prevent what I call ghost files. Files that get uploaded but will never be referenced because the user never went through the saving process that include the field context for said files. File is a weird type of field but it's not that different from any other field. When you edit a text field you are inputting text data which is volatile until you tell Grav to save and actually store that data. With files the process is similar, only now we have to deal with binary data which can be big in size, we need to take that data from a user system into the server, and we want to guarantee a fast use experience when the actually saving occurs. We went with the enqueue process to solve all of this. Before, when you picked your files it was literally like just typing text in a field. Upon save the binary data would be transmitted (uploaded) and permanently stored, exactly like the text you would type in an input field. The problem with trying to save immediately is that we don't have a clear picture of how the rest of the form looks like at that moment of upload, this is because all values are still very volatile and might still change in time until it is set in stone by the user action of saving. The only thing we know is that a user might want to save a file X for the field Y later in time, so we make Grav take off some of the load by moving file X from the user machine into the server and keep it there in case later in time the user decides to actually save. Only at that point we know we can safely move the file from our queue into the intended destination. I hope this helps putting in picture how and why things are working this way now and why I don't see us changing this behavior. To expand on your issue, I can see the strong relationship between the |
Thanks for your exhaustive explanation! |
Looks good! |
Cool! |
Here is what I am trying to do:
Example code for this case:
Problem:
my user can't upload a file and pick it with filepicker without saving the page first.
I think File should provide an optional button so that anyone can upload a file and have it available for an immediate use with FilePicker.
Note:
It also seems that there is no way to delete these images after they have been uploaded anywhere but in the page folder when you use "File".
Thank you for your consideration.
If the issue is not clear or explicit enough, please ask, I will provide details.
The text was updated successfully, but these errors were encountered: