Version 2.8 incorporates a change in behavior that several people, myself included, were pushing back against during development. This version will check for the existence of a file upon upload, and if a file with the same name already exists, it will display an error message and prevent upload. This makes it impossible to replace a file (like a PDF for example) with a new version of that file. Now, people will have to delete the old file on the server first, then upload the new one. Since the delete function is completely hidden (people have to know to right-click on a file name to delete the file), non-tech-savvy users won’t know what to do. All my clients are used to updating PDF files by simply uploading them, and this change creates a lot of hassle. I don’t think this change should have been implemented until an option to overwrite the existing file is included.
I’ll just go ahead and copy my response on GitHub here as well given you’ve decided to cross-post your concerns:
A PR was merged after discussion, and points raised after that merge did not lead to anyone providing a better pull request that matches the expectation of certain users before the release. Nothing’s being “pushed through” - there has simply not been a better PR for review before the release. A full revert would not make it better overall.
Users that want to overwrite existing files will first need to delete them explicitly rather than that happening magically and without any form of user feedback or interaction. It’s not impossible to do so.
I certainly understand some of your users may be accustomed to this and would welcome additional improvements that make it an optional checkbox of sorts in the upload window. Or a system setting that toggles it, perhaps, as proposed earlier in the thread.
Are you and your users also aware that any form of cache (e.g. CDNs like CloudFlare and browsers themselves) may cause an updated file with the same name to not show up to users, or at least not until those caches are refreshed? Perhaps the default behavior for PDFs is different from images which tend to be aggressively cached, but I’d be worried about that not making it through without a new filename regardless.
If you don’t want to upgrade, that’s absolutely your right to do so. However, spouting “I won’t be upgrading” is not constructive and I don’t see how that’s going to convince anyone to dedicate their free time to your cause.
Personally, I think this change is an improvement, but I can emphasize with people that have a different opinion. I’ve made you a proposal here, please let me know your thoughts on that.
You complicate the process. Now users need to delete the file on the server, and then upload the local file with the same name. And that’s all.
Yes, that’s simpler, but still this is what will happen. My clients will try to upload new PDFs, as usual. Now they see the message in red that the file already exists. What do I do now? They think. They push the upload button again. Nothing happens. To delete the old file, they have to cancel the upload, find the file in the list (which is often VERY long), delete it, then initiate the upload again. If indeed they can even figure that that’s what they have to do now. And no, they won’t try using the filter field to find their file quickly. The great majority of my clients are not tech-savvy, so they won’t try the filter field even though I’ve told them about it several times. I have about 150 MODX websites going, so even if 2/3 of my clients have problems with this, that’s 100 clients I need to get on calls with and walk them through how to upload files differently than they are used to.
MODX 2.8 came out yesterday, when did you had time for update 150 sites? 
You can remove this check - revolution/core/model/modx/sources/modfilemediasource.class.php at 723cd43fe538545eb9305f444b730781deccc428 · modxcms/revolution · GitHub
And the behavior will be as before.
The upload window indicates that the file exists in the message. I don’t think there should be any difficulties here. If the user can upload the file, then, it seems to me, he can delete file.
I put that way so that people would be curious, and would actually read this post! Hey, it caught your attention, didn’t it? 
It wasn’t intended to be confrontational. In general, I’m extremely appreciative of all the hard work all the volunteer developers do to keep MODX growing and improving. This one change is a very rare case that makes things more difficult for me and my clients. I wanted to find out if other people out there feel the same way.
But I also wanted to express how strongly I feel about this, rather than just sort of go along and say, well, OK, whatever, I’ll just roll with it. It really is going to add hours of time to my already full schedule having to retrain clients. Very few of them are tech-savvy enough to just get what the change is and adapt quickly.
As for PDFs getting cached by CDNs, yes I know about all that, and just a few of my clients use Cloudflare. I’ve already set up a MODX menu for them that links to Cloudflare and clears the cache after they’ve uploaded a new version of a PDF. Retaining the name is important in cases where they’ve publicized a certain PDF in social media or email promotion, or links to the PDF that were created on external websites, so the name of the PDF can’t be changed.
As an example, I maintain a bunch of websites for a conference production company, and there are individual producers who work on individual events. These producers may hire additional help to maintain content. Typically they are busy, if not overworked, and they need to upload new PDF versions of conference agendas, or maybe pass off the task to a short-term helper. These people just want to get into the agenda page on the site and upload the new PDF. I can’t easily keep track of all the people involved and explain that they have to delete old files (and how to do that, since it’s not obvious) to upload new ones.
Well, I could, using SiteDash. That’s generally how I keep almost all my sites up to date, because there are so many.
Thanks for the link showing where to disable the check, although I’ll have to do that manually on each site after upgrading. 
I love using that remote upgrade button too. 
I’m seeing some more trees appearing on ecologi so I take it you’d like me to add that setting then?
Believe it or not, many of my clients wouldn’t be able to figure that out, because that function is completely hidden. You have to know to right-click on a file to delete it. You can’t just select a file and have a button or link to delete it show up somewhere. It’s one of the behaviors in MODX in general that clients take some time to get used to. All sorts of actions are only available by right-clicking on something. I have to keep saying, “when in doubt, right-click!”
Yes, I added trees. Such a cool service!
Maybe I’ll even add some more at some point soon . . .
Thanks, Mark and Ruslan, your comments have sharpened what I see as the problem, and I’ve amended my initial post above, along with the post title.
Can you create an issue on github? About displaying a delete button, for example, on a file. It would be helpful to improve this kind of behavior in the 3.x branch.
OK, will do. And thanks for all your hard work!
Always happy to help!
This issue affects me, but not seriously.
I did want to mention, though, the possibility that a user facing a lot of similarly named files could easily delete the wrong one. That could cause serious problems that might be difficult to diagnose and repair.
I would think an overwrite_files_on_upload System Setting would be a relatively easy fix, though I haven’t looked at the code.
Thanks for the trees 
Here’s a pull request: Add `upload_check_exists` system setting to allow overwriting files with same name by Mark-H · Pull Request #15285 · modxcms/revolution · GitHub Will need to get reviewed, of course.
What you suggested is indeed what I implemented @bobray, only run the check when the setting (upload_check_exists) is enabled.
Excellent work!! 
Situations like this are the ultimate reason why Modx is undeniably my current choice.
You guys really rock! Real and solid solutions for the “day-to-day” concerns.
Thank you for all your involvement and hard work.
Can’t wait for Modx3!
Cheers
Thanks a lot @rainbowtiger for sharing your concerns and feedback! Thanks to everyone involved to solve this issue!