Can't overwrite media

[devlife]

I have a client who wants to be able to overwrite media. The tenant is configured with Azure Storage. If he deletes an image, Image.png and then uploads a different image with the same name then we still see the original image thumbnail.

I've tried purging media cache as well but that didn't have any effect.

[deanmarcussen]

Have you tried clearing your browser cache?

ImageSharp uses a default browser cache of 14 days (from memory), so even when evicted from the Media Cache (which would happen automatically if the item is deleted from the media library), the browser will still cache the image for a period of time.

ImageSharp also evaluates based on last modified dates, but when using blob storage this translates into the date it was uploaded into blob storage (when not using blob storage, this can be an issue, if you are just renaming files to test with, as the last modified date doesn't change during a rename)

We also have cache busting support for images (you can apply this to the front end)

But we don't yet have that the admin area.

Here's the original issue for this #3925

I did open a pr but it never got merged, so I closed it.

Perhaps it should be a setting for the media app?

Rather than on by default (which the pr did)

[devlife]

No I haven't tried clearing browser cache. That def seems like a pain. Out of curiosity is there a reason not to reopen the PR?

[deanmarcussen]

It's a pretty simple PR, probably just need to get the design requirements correct, though i know Sebastien was concerned about the performance implications.
(Note they are memory cached after the first request)

Requirements request:

Do we want default media cache busting as a setting?

This would be then applied to the admin thumbnails, and the asset_url helpers

[devlife]

Personally I think that would be a good addition assuming I'm not missing some other reason it hasn't been implemented yet. And the memory caching makes sense. If we could clear that specific cached item I think that would be fantastic.

[deanmarcussen]

@devlife have you verified this was browser cache related?

[devlife]

@deanmarcussen sorry I didn't realize you were waiting for me to verify. I will do so this week.

[Skrypt]

I've experienced this issue when using the Media Gallery directly. Though when I'm using a "Media Attached Field" I never get this issue because of the fact that when we upload a new file it generates a new uid for it everytime. So if I delete one file on the Media field and reupload the same file it won't use the same name.ext.

Now if you upload a file directly with the media gallery that has the same name than the previous one in a folder. You will get this issue because it will try to get that file from the ms-cache folder without overwriting the one that is in that cache.

[sebastienros]

Can we try to implement the cache with the FileInfo modified time? This doesn't require FileWatcher

[deanmarcussen]

If it is possible to make it work without a file watcher we could then have a site setting to control this behaviour by default

[deanmarcussen]

Hmm, as i understand we would have to grab the file info, at least periodically, to see maybe first if the file still

From your other comment @jtkech

So the thinking from Seb was to not cache the file info at all, but do a lookup for for the fileinfo, rather than from the cache, and use the ModifiedDate for the version, rather the hash as we are currently.

I'm thinking this is for media, and static files that are in the tenant file provider, but still for embedded resources, that cannot change, we could continue to use the static cache.

I also need to take a look, and remember all that we did back then...

[jtkech]

@deanmarcussen

Okay cool, so it seems that i understood it quite correctly ;) when i said in my related comment in your other PR

... Or if it is fast enough (which is the case for embedded files) maybe grab this file info each time we generate an url, if so maybe we could just append something re-computed from this modified time (if it has changed) in place of doing a hash on the whole file ...

---

I'm thinking this is for media, and static files that are in the tenant file provider, but still for embedded resources, that cannot change, we could continue to use the static cache.

Okay. Hmm maybe also for embedded files, currently if you change some file contents and redeploy your app the appended version based on the content hash will change to bust e.g. browser caches, but it would be the same by using the modified time that here is the last modified time of the module assembly file.