As described here I intend to use TW for a usecase especially difficult for TW: Editing a tiddler in a narrow time-window with different users.
A problem I encountered when working on different computers was that sometimes TW is not loaded freshly but from the cache. This could result in overwriting many newer edits and annoying users
Is there a way to prevent this?
Which setup is most useful to cope with this problem?
I think you can add these to the $:/core/templates/tiddlywiki5.html
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
see http - How do we control web page caching, across all browsers? - Stack Overflow
4 Likes
Rather than modifying $:/core/templates/tiddlywiki5.html (which can interfere with future updates to the TWCore), you can place these <meta> elements into a tiddler tagged with $:/tags/RawMarkup and then save-and-reload to automatically add them to the end of the <head> section of the HTML file.
-e
6 Likes
Can someone give a fuller explanation of what this does and particularly when not done what is the result?
It seems to me if this knowledge is of any value to anyone, it may be something everyone can find out about.
In the concept of TW it may become a problem, if you work with different computers because somtimes TW someetimes restarts using the last downloaded version - which may reult in loosing the recent changes.
AFAIK this also happens if you work with TW, open a new page and the go back with the browserhistory button.
This trick can avoid this problem by switching off the cache so that TW cannot be reloaded from there.
I bundled @buggyj 's and @EricShulman’s solution in a json here
$ _config_noCache.json (345 Bytes)
1 Like
I do believe there are some subtle issues not addressed in this thread that also influence the out come. But thanks for explaining.
i have a feeling that unintended (i.e. default) use of browser cache is an unresolved (and un-noticed) data loss issue
as a user, unless you learn about browsers and browser cache, you will probably be unaware that it can affect single-file tiddlywiki accessed via browser or when switching devices
as a user, this kind of data loss will also be difficult to notice unless you are working on the same tiddler repeatedly; for developers it might also be difficult to test for
i am currently working around this by (on desktop) only opening single-file tw in a cache-disabled browser instance (via script) but hope to transition to one of the solutions in this thread as i also use mobile (ios quine)
1 Like
I am sot so sure about this, I personally have never needed to worry about the browser cache, I use tiddlywiki a lot. The key is just ensuring not opening the same single file wiki twice and ensuring you save before opening/reloading in another browser/tab.
- In this case I believe the cache must reload because underlying file has changed.
- In the milti-user case (single file wiki) a logical checkout mechanism, only available for a few seconds after loading and if not already checked out, so a reload is necessary later, should stop “stale” tabs, and then reload the cache.
This solution doesn’t seem to be working for me on either my phone or Chromebook. I’m serving the wiki over WebDAV and it frequently loads from cache rather than fresh.
I figured out why this doesn’t work for me over WebDAV. Apparently when served via http, the metadata from the http response header is preferred over metadata set in the webpage. This isn’t an issue with file:// uri’s. I’m not sure that there is a solution unless one is able to modify the server.