These are pointers relating to the caching problem (often, when hitting preview, the view that one returns to is the old view, not the one that got saved).

• From RichardDonkin:, 20 Jan 2002 I've had this a few times using IE6 (or at least what I think is the same problem). Here's what happened just now on twiki.org, and a workaround related to BrowserAndProxyCacheControl - let me know if this is the same problem, and if the workaround helps. (It would be best to log a BugReport about this with steps to reproduce, I'll do that if this is reproducible.)
  1. Edit a page on TWiki.org at least once, preview and save it.
  2. In same browser session, edit the page again, make a change, then Preview and hit Save Changes
  3. Browser displays previous state of the view page, i.e. state after step 1
  4. With IE5 or IE6, try hitting Ctrl/Refresh to do a 'hard reload' (should bypass all caches) - this shows the latest state of the page, indicating that the Save actually worked.

I was using the JunkBuster non-caching proxy for this test. See BackFromPreviewLosesText (now fixed by cache control headers) for some discussion of caching issues, as well as BrowserAndProxyCacheControl - if this is really what's happening in this problem, all that's required is that the view URL generated from the save script needs to have suitable no-caching headers to ensure that the browser never shows a cached version of the page.

• From RichardDonkin, 19 Mar 2002: Could you provide a bit more info about your proxy cache setup (transparent or not?) and browser/CGI.pm details, ideally by adding to ViewAfterSaveCachesOldPage, or ViewAfterSaveLosesText. There are really two bugs here, one cache-related and the other not. I'd like to nail the underlying bugs using a simple BrowserAndProxyCacheControl or whatever, but there needs to be a better way of reproducing them - and I've just had the non-cache-related variant...

-- ThomasWeigert - 05 Aug 2002