Duplicate file upload when another entry has it attached already. about symphonycms

[simoneeconomo]

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)

[simoneeconomo]

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]

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

[simoneeconomo]

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

[nilshoerrmann]

@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?

[simoneeconomo]

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]

Where do I find your prototype?

[simoneeconomo]

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

[nilshoerrmann]

Ah right :D

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

[petsagouris]

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]

@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?

[simoneeconomo]

No objections :)

[jensscherbl]

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

[michael-e]

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]

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

[michael-e]

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 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]

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]

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]

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.)