Some good points, but first of all, let me explain exactly what the problem is and why it can't be solved by some of your other suggestions.
What is the problem?
The problem is your browser cache, and potentially CDN cache (for example if you are using Cloudflare). There is nothing in X3 that is "keeping" the old image, and there is nothing we can "delete" up front or anything. All the data is on the server is 100% correct, but your browser decides to output old images from it's cache.
For example, you have an image at the following path (relative to domain):
/folder/path/image.jpg
The you replace that image with a NEW image, the path remains the same:
/folder/path/image.jpg
When that image is requested in browser, your browser then goes "Hey, I have that path already cached, and I was instructed to cache this image for 1 year, therefore I will serve the cached image from browser". The old image is then served from browser.
How is this solved in modern web design?
Because cache is important, in modern web design, all platforms use a renaming scheme to update static assets like images, CSS and Javascript. This is the only proper way to make sure you always serve fresh assets when assets are updated.
How do other platforms solve this?
Most other platforms, for example Google, Flickr or other database-based image galleries, have images locked to a database, and will always use hash-based names for images once they are uploaded. Try downloading an image from Facebook, Flickr or Google, and the name will be something like 5698040331133625348_n.jpg (often longer). When/if the image changes, the ID will change also ... Any "title" or "caption" for the image, is entirely separated from the image.
In X3, you keep the real file names, but if you then want to avoid caching issues, you would yourself need to increment the filename ... For example if you had "image.jpg", delete it and upload "image-A.jpg". If you don't like the "name", then why not use titles/captions instead? You can't rely on a fixed image name, especially if you intend to update the image.
Disable cache?
Another option would be to entirely disable cache headers on your server, but this is very unproductive. This means static assets (like images) will never cache in browser or on CDN, and will ultimately make your website slower.
trpgforum wrote:Couldn't this problem be solved finally and cleanly with a function or, even better, if old disturbing data is definitely deleted or overwritten when uploading?
As you may understand from the above, all old data is definitely 100% deleted and 100% overwritten. This is not the problem. The problem is that when your browser makes a request to a path/to/image.jpg that it has requested earlier, this path is cached in browser. It's not in X3, but your browser, and X3 can't delete cache in your browser.
Just for clarity, if you made your own website (not X3), and did the same (replace an image with another image with the same name), the exact same thing would happen. This is not an X3-specific issue, and I wouldn't write this long a post if there was an obvious solution. It's the way of the modern web.
Solutions
- Rename the new image incrementally when you update. This would be the recommended solution, if you posted this question in some web developer forum.
- Disable image cache headers on server. This would basically tell browsers to NOT cache any images, and would therefore always load the latest/newest image updated on server. This not a recommended solution, because caching is an important feature of web performance. It would always load images from your server, instead of using cache, even for images that never change in 10 years.
- There could be a solution in X3, where I include the image's server date in URL, for example "path/to/image.jpg?1706069910" ... The date (epoch time) would change when the image gets updated on server, and would therefore force the browser to refresh, because the path changes. This could be a solution, although it is considered a bit of a "hack".
I may very well implement solution #3 in a future release.