TYPO3 Core

Hi Mathias,

Thanks for replying. To answer your question: Yes, file and filename are identical. Currently, what happens on uploading the file, is a JavaScript confirm to overwrite the existing file or not. I'm currently not able to access an installation as I'm on the road but I'll try to give more details, if needed, when I'm back (latest on Monday).

Ok, thanks for the feedback.
I am a bit puzzled to be honest, because the entire idea of FAL is to NOT have the file_01.jpg?

I think I am missing something here :)

@Matthias: This is not about the internal renaming for each Content Record (like in previous TYPO3 versions), but about the file upload dialog.

The JS for this dialog needs to be tuned to allow more choices and better error handling.

Especially for drag&drop uploading, errors need to be handled via client side, inside the JS, because the page will not reload.

When I upload a file and then try to upload that file again, I get the following question:

"Shall existing files be overwritten?"

If I click "Ok" here, which suggests the file should be actually overwritten, everything works fine as would be the logic behind FAL as you mention it.

If I click "Abort", which in context to the question, if existing files should be overwritten, should, IMO, mean "No, but upload them and append _01, _02, etc.", I get the following error message:

"No unique filename available in "/user_upload/bilder/test2/"! Upload of the file "image.jpg" failed!"

That is because the logic behind "Abort" is not how I described it, but "Abort everything" which doesn't make any sense in context to the question that is asked in the backend. Therefore, and to maintain earlier functionality, because in fact it is a user friendly way to have different versions of files for an editor, there shouldn't be a coFnfirm with true/false but three options "Yes, No, Abort". And in my first post, I can see in the core, that this functionality is actually there, but never achieved because of the yes/no confirm box.

Another solution would be to change the question in the confirm box, although it would mean decrease in user friendliness for editors. 

How do you propose to solve it, if the idea behind FAL is to not have _01, _02, etc.?

Although it seems like a easy fix I'm afraid it isn't. See the releated issue I linked.

Seems to me that this is more an endless discussion again about a trivial thing, given the date of the bug entry you linked. I don't get why, even more in this case, because it's a LTS version, clearly unfinished stuff makes it to the core of TYPO3. The way FAL was introduced is just one complete mess.

While I agree that FAL has a lot of things that need to be improved, I can't tell any part within TYPO3 that you can consider "finished" :)

I think this discussion is not endless, but rather fruitful because we need more feedback on the expected behavior by you, the users.

What does not help is an attitude like "why didn't you see this?" because noone missed behavior on purpose.

Thus I consider it important to discuss these things until we have reached consensus about how it should behave and then implement it.

I'm sorry, if my attitude seemed inappropriate, it wasn't my intention to blame anyone, but to point out, that everything is ready for the feature (3 options) and then a confirm box is used (true/false). This is not really about missing features IMHO, but just unfinished. I'm okay with a piece of software not really being "finished", but to introduce a new feature and to remove features along the way that have been there for ages with no mention of it that it has been removed is rather difficult to understand. Of course I'll be giving more feedback along the way, because that's important as you say, but the first and most important thing, besides NEW features or how it should behave, should be reintroducing the OLD ones first.

Maybe that came out too harsh from my side, my apologies.

We will try to tackle this issue during our FAL sprint in Essen/GER in Q1/2015.
Again: Thanks for clearing up the expected behavior.

For me the behaviour is as expected. I have TYPO3 installations with several editor who very often upload the same files again and again. This is not very useful.

The normal way most operation systems behave is not to allow to upload a file with the same file name again. Normally you will be asked to replace this file.

But for me it should be possible to replace a file in FAL by uploading the same filename again ("Do you like to replace yes/no"). But this is a feature wish :).

While I understand and agree with the former behaviour having been "removed" and I understand the problematic of keeping multiple versions of the same file "automatically by suffixing", I have the feeling that it is not the general use case for FAL usage:

• It most cases, the user is actually willing to update an image or a file and not get another version into the system, so current behaviour of either replacing or aborting is the one making most sense
• It is quite easy for people to manually rename their file prior to upload if they really want multiple versions of the same file

However, I read the concern about aborting everything or nothing and, together with an enhancement with that "weird" behaviour, I would suggest something that would certainly make everyone happy:

• DO NOT ask the question regarding overwriting or not prior to uploading, but wait until there is a case
• This question should be asked for each and every file, not "globally" (with an option to say "do the same for other conflicts")
• To this regards, instead of telling the user "there is already file XY, do you want to overwrite it, since the file is already (emporary) uploaded but not moved to its final place, we could do:
  • Give additional info such as date of last modification / file size of existing one vs new one
  • Give user the possibily to 1) cancel (this very specific file upload) or 2) replace existing file (current behaviour) or 3) upload anyway and auto-rename

This way we will even enhance the UX of uploading file by not asking useless question (what to do if existing when this does not make sense) and let user do exactly what he wants.

In addition, we could even think of preventing overwrite/renaming if checksum is identical since it does really not make sense to have multiple times the same file (I hardly see a good reason to do so).

+1, sounds like a proper solution.

I wrote someting down here: https://forge.typo3.org/projects/typo3cms-core/issues?query_id=167

Most other file systems act like this.

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338