Make the overwrite original file description more user friendly

@bkosborne, what are your thoughts re: the patch → in #16 📌 Make the overwrite original file description more user friendly Needs work

1. I agree using radio buttons is better here as it can present the two choices even better.
2. I don't think we should add this warning text though "'Warning: people may not see the updated content of static files (.txt, .pdf, etc) because they can be cached by external caches for a long time." - we cannot know how people have configured the caching of their static assets on their sites. This could lead to more confusion.
3. Current patch changes the default behavior, I don't think we should do that
4. I think the field description is still a bit confusing, because it's really only applicable if the first option was selected. Ideally that description would only show if the first option was selected. Not sure that can be done easily. Maybe with #states. I could be overthinking it

Re #18 point 2: There does need to be something about caching. This is site-editor-facing stuff. My clients got confused when they "replaced" a file but the old version was cached by their (and their customers') browsers.

Suggestions for better/simpler wording?

Re #18 point 2: There does need to be something about caching. This is site-editor-facing stuff. My clients get confused when they "replace" a file but the old version remains cached by their (and their customers') browsers.

Something simpler?

"If the file does not appear updated after saving, try clearing your browser cache."

This is why my original request was to make the text configurable - so site builders with knowledge of the static asset caching setup could provide better help.

> I don't think we should add this warning text though "'Warning: people may not see the updated content of static files (.txt, .pdf, etc) because they can be cached by external caches for a long time." - we cannot know how people have configured the caching of their static assets on their sites. This could lead to more confusion.

This warning is critical for our editors, specifically because external caches often tend to ignore any static asset caching rules as defined by the origin server. The static asset caching on the origin server is also not something people usually have access to (not through Drupal, anyway) and by default it is set to "forever".

This means that 99% of the time, using the same file name for a PDF will result in people not seeing updates to that file -- which is why Drupal adds the _0 and _1 to the end of the files in the first place. It's true that we can't know if people are in the 1% who have mitigated these risks, but I'd prefer that we make life less frustrating for the 99%.

Drupal tries to save people from this confusion by not explaining anything, and automatically adding the _0 and _1, which often leads to frustration for editors. Here we're giving them the choice to avoid that frustration, by potentially causing another.

I would like to explain the risks associated with using the same file name, so that if people do choose to keep it, they won't be frustrated by not seeing any changes to the file they keep replacing.

I agree that this explanation may lead to confusion, but that's mostly because most editors don't already understand that static asset caching is forever, and that things like PDFs are considered static. I'd prefer if we could iterate until we find something better, rather than removing the warning entirely. :) Do you have recommendations on how to improve the language to make it less confusing?

Disagree with #22. This isn't something the users should be confronted with or have to think about. Of course it's something that should be put on the module page an the readme of this module, if it is impossible to solve this technically.

Okay, there's lots of compelling arguments laid out a this point. I'm OK with adding a module configuration page, where the site owner can configure text that appears if the option to replace is selected.

In there, a site owner can indicate the site-specific details around caching. For example, some sites may be configured such that browser caches are disabled for static file assets like PDFs, and files are programmatically invalidated from other external caches like CDNs automatically. In this case, no warning should be necessary. On the other hand, some site may be configured such that browser caches hold onto the files for 5 minutes.

I guess it's worth empowering site owners to inform their users of the site's specific caching rules in non-technical terms in their own words.