Skip to content
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

Closed
anthonygrignoux opened this issue Sep 21, 2016 · 6 comments
Assignees

Comments

@anthonygrignoux
Copy link

Here is what I am trying to do:

  • have my user upload a file in another folder than the current page folder (so without PageMediaSelect but with File instead)
  • have my user pick one of those uploaded images with FilePicker

Example code for this case:

        slider:
          type: section
          title: Slider
          underline: true
          fields:
            sildefile:
              type: file
              label: Upload an image
              destination: 'self@/test'
              multiple: false
              accept:
                - image/*
            header.slideimage:
              type: filepicker
              label: Choose the image
              folder: 'self@/test'
              preview_images: true
              accept:
                - .png
                - .jpg
                - .jpeg
                - .gif

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.

@rhukster
Copy link
Member

@w00fz can provide a better answer than I as he just refactored this field.

@w00fz
Copy link
Member

w00fz commented Sep 21, 2016

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.
However, this caused some headaches when files were big because saving a page would take a lot of time depending on how many files and how big they were. Now, instead, that volatile data is uploaded instantaneously and held in a temporary queue on the server and only moved to destination when the user gives the ok (via save). If this save never happens, that temporary queue is just cleared out with any temporary file that was uploaded.

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 file and filepicker fields so it would make sense to improve the FilePicker. We could have an optimistic setting that allows the FilePicker to also list all currently pending files, if any. That way the user can upload and still select them.

@anthonygrignoux
Copy link
Author

Thanks for your exhaustive explanation!

@w00fz w00fz added enhancement and removed question labels Oct 2, 2016
@w00fz w00fz closed this as completed in c4ed5af Oct 2, 2016
@w00fz
Copy link
Member

w00fz commented Oct 2, 2016

Ok this is implemented now. You will be now able to optimistically select uploaded files from a filepicker field.

pending-uploads

@rhukster
Copy link
Member

rhukster commented Oct 2, 2016

Looks good!

@flaviocopes
Copy link
Contributor

Cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants