If I follow you correctly, you're saying that you're directly including a static resource in a community with a url like /resources/my_resource_png
instead of using the preferred format of {!URLFOR($Resource.my_resource_png)}
.
One reason to prefer the second is that it generates the actual URL based on the last modified time of the resource. So it renders as something like /resource/1535031348000/my_resource_png
. Part of the reason for that is so that browsers know not to use the cached version if the last modified version has changed - uploading a new version of the resource changes the URL.
The fact that you get the same version is not a bug in SF, in fact it's nothing to do with SF, it's all about the browser.
If you really cannot use the {!URLFOR($Resource.my_resource_png)}
, you can always just throw your own version number on the end of an explicit reference e.g. /resources/my_resource_png?v2
. I would strongly encourage you to use $Resource
, though,
Edit
Questioner has clarified that they'd using Lightning. In Lightning, you refer to the resource like this:
<ltng:require scripts="{!$Resource.my_resource_png}"
afterScriptsLoaded="{!c.afterScriptsLoaded}"
/>
That has the same effect as what I described above for Visualforce.
CTRL
+F5
). Usually I use a guest window in chrome to test cache issues with static resource. Also using$Resource.StaticResourceName
is a best practice.