Hi, I am developing some widgets. They are served up from a development server.
using chrome as the client.
Having issues getting the latest widgets off the development server, sometimes they are a few versions behind (cached).
I have tried “refreshing”, disconnect/reconnect , private browser and I get sporadically different levels of cached widgets . I have also tried deleting “application” data.
It means a post (reply) was flagged and resulted in the post being hidden, which means moderators and above can see the reply but for most it is hidden. The post has not been deleted.
If a moderator decides the flag is valid, then one of several actions can occur.
In your case it means you see that a reply exist but not the details.
Since I can read the reply, all I can say is that flagging was a wise decision.
Have you tried implementing Cache Busting for your widget resource URLs on the server?
I ran into the same issue while testing widget changes, so I implemented hash/version calculation based on the widget code. The resources are served like this:
ui://widgets/summary.html?v=c221706e114f3023
On my server, even a small layout change regenerates the hash on re-init, so after a “refreshing” new hashes are generated and the UI will always fetch the fresh content instead of a cache.
yes. I included an epoch time stamp , so when you “refresh” it changes the widget url and I can see them in the settings.
Update: SOLVED, I think/hope: I was only including the “bust” in eacg tool/template url.. but I just noticed it was not in the other “template” url (further down the page). So that seems to have fixed it .
I also includes some no-cache directives in the MCP url too, but I don’t think that solved it.
no worries. Paul… mmm issue started happening again so it seems like I had somehow flushed the cashe… I managed to flush it a few times, but it’s still not 100% consistent
I’ve seen this too. The most reliable fix seems to be “version the widget URI”, not just the underlying HTML assets.
Two patterns that helped:
Add cache-busting to the widget resource URL (e.g., ?v=), and make sure you add it everywhere you reference the template (tool/template + any other template URL).
Even better: bump a widget version number and bake it into the widget URI (so refresh pulls new metadata and the URI changes → forces a fetch).
If you do (2), treat every deploy as a new widget version (scripted bump).