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

Duplicate file upload when another entry has it attached already. #672

Closed
brendo opened this Issue Jun 16, 2011 · 20 comments

Comments

Projects
None yet
8 participants
@brendo
Member

brendo commented Jun 16, 2011

Migrated from Symphony Issue 608 (paraphrased heavily)

@ahwayakchih

When file name (instead of real file upload) is passed in POST, field could try to duplicate file if another entry already has this one attached. That would make entry duplication work with file uploads, and allow to create JavaScript that could switch between file upload and selecting file name (for example, user could decide if he/she wants to upload new file, or select existing one).

@brendo

User actions:

  1. File is uploaded and entry is saved.
  2. Another entry is created and a file of same name is uploaded and clashes
  3. Ask User, use this file, rename uploaded file or cancel

Use this file

Allow user to click on the image and open it in a new window to verify it's the same. This will duplicate the existing file and append a numerical suffix to the filename (-1, -2) etc. This is a common system used by operating systems so it should be relatively familiar to the user.

Rename uploaded file

Allows a user to rename the file they are uploading. This will need to trigger the same logic to repeat again to ensure the renamed name is still unique.

Cancel

The current behaviour

@eKoeS

Right, but my question is: what happens when there's a file clash? Is the entry already "saved" or not? If a green system message appears on top, then the user might think everything is okay and leave the page even if his/her action is still required by the upload field.

@brendo

The usual yellow message saying there was an error when saving, please see below would appear

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Oct 29, 2011

I was thinking about using JavaScript to make an AJAX request, so that if a file with that name is already present, the user knows that in advance before saving the page ( = less frustration and quicker workflow)

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Oct 29, 2011

So, here's a quick sketch of what I've been thinking of:

http://dl.dropbox.com/u/4096074/symphony/upload_field.png

Note: The "choose..." button is the upload button. Sorry for the bad labeling. ;)

  1. A file is chosen.
  2. An AJAX request is made to check for conflicts (if the response code is 200, then there's a conflict)
  3. If conflicts arise, the user is shown a message to view the existing file. Then, he/she is asked to choose between:
    1. Using the existing file
    2. Creating a duplicate (automatically renames the file)
  4. Based on the chosen action, a message is shown saying "Upon saving, $chosen_action_message", with a link to cancel the setting and choose a different action (takes the user back to 3).

I was also thinking of a new field settings for the Upload Field that automatically handles conflicts based on what you set as a default action. This might be useful in cases when you don't want your client to even care about filenames clashes.

@brendo

This comment has been minimized.

Member

brendo commented Oct 29, 2011

All sounds good to me, nice mockup too. Do you want to take care of this?

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Oct 29, 2011

Sure! Will work on it tomorrow (and will probably ask @nilshoerrmann for a comment).

@ghost ghost assigned eKoeS Oct 29, 2011

@nilshoerrmann

This comment has been minimized.

Member

nilshoerrmann commented Mar 7, 2012

@eKoeS I know you are quite busy, but is this still something you'd like to take care of? Maybe during the Hackathon (in case you're participating?

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Mar 7, 2012

is this still something you'd like to take care of? Maybe during the Hackathon (in case you're participating?

I'd like if you could have a look at my prototype sketch and make your own first. I'd be more than happy to implement it, even if I'm not sure I'll be able to attend the Hackathon.

@nilshoerrmann

This comment has been minimized.

Member

nilshoerrmann commented Mar 7, 2012

Where do I find your prototype?

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Mar 7, 2012

Sorry, I mean "sketch" :) It's up there, 5 comments above yours.

@nilshoerrmann

This comment has been minimized.

Member

nilshoerrmann commented Mar 7, 2012

Ah right :D

If I understand that concept correctly, I think that should work quite well.

@petsagouris

This comment has been minimized.

petsagouris commented Jul 26, 2012

Isn't this just over-engineered? Just rename the file (add a filename-%d.ext) and notify the user about it after everything has happened. This is the user's responsibility.

@brendo

This comment has been minimized.

Member

brendo commented Jul 27, 2012

@petsagouris brings up a good point.

If we defaulted to the Use this file approach outlined in the OP, with a slight difference, we upload the current document and renamed it instead of altering the original document, this allows a user to upload the file without interruption. It also simplifies the field logic a great deal (and this issue).

Any objections?

@eKoeS

This comment has been minimized.

Contributor

eKoeS commented Jul 30, 2012

No objections :)

@brendo brendo closed this in 1e4849c Jul 31, 2012

@jensscherbl

This comment has been minimized.

Member

jensscherbl commented Jul 31, 2012

Am I right when assuming this change makes the Unique Upload Field extension obsolete?

@michael-e

This comment has been minimized.

Member

michael-e commented Aug 1, 2012

No, it won't. One purpose of the Unique Upload Field is to prevent caching of old files if you re-upload a file using the same name.

I'd love to see a (configurable) solution that renders my extension useless.

@michael-e

This comment has been minimized.

Member

michael-e commented Aug 1, 2012

Or will this logic create an newly indexed filename if I re-upload a file???

@michael-e

This comment has been minimized.

Member

michael-e commented Aug 13, 2012

Yeah, in theory they do. :-) But especially Safari caches very aggressively (images and CSS files alike). This is why I invented the Unique File Upload extension in the first place.

@designermonkey

This comment has been minimized.

Member

designermonkey commented Aug 14, 2012

This is very late for me to chime in, but I have to say that @michael-e's field is the one I use as default instead of the normal field.

I would like to see it slightly differently done though ;o)

All I will say is that I think if we're going down the route of unique names for uploaded files, then @michael-e's approach should be the default. We had some discussion at the 2011 Symposium about unifying the main versions of fields into the default core fields, one of which was this case. The other was Text Box instead of all the text fields, but that's another discussion.

@michael-e I will make my proposal of ideas to you on your field's issue tracker, I can't remember if we already discussed it.

@brendo

This comment has been minimized.

Member

brendo commented Aug 14, 2012

To be honest I'm fine with the renaming approach we have currently.
This is consistent with Windows and Mac OS's so for the most part users
will be more familiar with 1/2/3 being added to their file instead of a
random hash/timestamp. Michael's field will still function with these
changes, so they can coexist for users who need more fine grained
control.

@creativedutchmen

This comment has been minimized.

Member

creativedutchmen commented Aug 14, 2012

Sure, users are used to this, but normally adding 1/2/3 won't break anything. We are creating a web-platform here, and it should be optimised for the web, too.

I think an unusual filename is a small price to pay for something that will prevent a lot of problems. Because, be honest, can you name a single website where too aggressive caches would not be a problem at all? I can't.

Which means I think every website should get the other version, which renders the default field useless.

@michael-e

This comment has been minimized.

Member

michael-e commented Aug 14, 2012

I think the current approach is a big step forward, but I have some points to add here:

  • The renaming logic depends on the user (author) either first deleting the old file (in this case the upload may result in the same filename) or simply replacing the current file (in which case the new file will have a suffix appended to the filename). I don't expect any authors to understand the difference between those two workflows, and thus the possible addition of a suffix can not be a solution to caching problems (in Safari or in proxy servers). My intention always was to take the responsibility away from authors.
  • I would appreciate any generic solution that makes extensions superfluous. (This is a good idea for all core fields. We have too many field extensions for features that might be solved in core fields, e.g. uniqueness demands.) Unfortunately I don't see that the Unique Upload Field has become useless with these changes to the core Upload Field. (See above.)
  • @designermonkey: I would really appreciate a generic solution in the core field. If we improve my extension, we will take away the pressure form the core field, so it will never make my extension useless. So, is it wise (to improve my extension)?
  • In my experience users don't have any problems with hashes appended to filenames. No one ever even asked about it. (It's just us, assuming that the users might find it ugly.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment