create new tag
, view all tags
See also RefreshEditPageDiscuss

When I edit page in loop like Edit -> Preview Changes -> Save Changes -> Edit -> etc., I should press "Refresh" button of the browser at Edit page, to replace cached form with old text of the page with new one. It may be useful to add HTTP-EQUIV in template of header to decrease expiration time of the page.

-- IvAn - 02 Aug 2000

What browser on what platform are you using? It works fine with Netscape and IE on Windows. Not expiring the content has the advantage that you can hit the back button on Preview to make more changes. You can add an HTTP-EQUIV meta tag to your templates.

Or better, create a new variable %HTTP_EQUIV_ON_EDIT% in TWikiPreferences like this: (This works for the latest Alpha version)

  • Set HTTP_EQUIV_ON_EDIT = <meta http-equiv="Expires" content="%GMTIME{"day month, year - hour:min:sec"}% GMT">

Then use the %HTTP_EQUIV_ON_EDIT% in the head of the edit.tmpl template file. The variable can be overloaded by user preferences.

I made the changes to TWikialpha, but left the variable empty by default. To make it even, I defined also %HTTP_EQUIV_ON_VIEW% and %HTTP_EQUIV_ON_PREVIEW% .

-- PeterThoeny - 15 Aug 2000

To see this effect, use any browser, just switch "refresh mode" setting from its default "Always" setting. Browser will treat any page as "static" if there are no "?" in URL. (That's the most important difference between "GET" and "POST" HTTP methods from client's side).

-- IvAn - 02 Aug 2000

I was also bitten by this bug and lost some editing this way (re-editing a page fills the textfield with wrong contents). I think this default behavior is too dangerous for most users. (tested on linux with netscape, opera, konqueror). Moreover hitting the back button while in preview changes works even after applying my patch to set expiration date, so I suggest setting definitively the expiration date to 0 directly in the perl code.

Attached is my patch (setting exp date in 1999):

-- ColasNahaboo - 09 Mar 2001

A solution working for all browsers could be:

  • make the edit page not expire (but all other still expire immediately)
  • but the view.tmpl links to an edit url with extra random garbage at end. eg .../edit/Test/TestTopic1/56735872
  • edit script discards this garbage

-- ColasNahaboo - 18 Apr 2001

Ok, I have found the proper solution and implemented a patch. What is needed in this case is:

  • a way to tell the browser not to reuse the edit view
  • but not by an expire so we can do a back and find back contents
The solution is to make the edit page not expiring, but generate a new random URL at each time we click on edit. A trick is to make the random chars appended to the URL made of chars removed by the $securityFilter: | and 0x01-0x1f chars, but still part of the legal URL syntax.

To this end:

1 apply my updated patch http://www.inria.fr/koala/colas/TWiki/PatchForExpires2.txt to make all pages expire immediately, except edit (otherwise you will miss pages edits by others or preview may be bad)

2 in bin/wiki.pm, add the function (_war:

## Random URL:
# returns 4 random bytes in 0x01-0x1f range in %xx form
# (except for %0a, newline, for fear of bad regexp matches)

# =========================
sub randomURL
  my (@hexctrlchar) = (qw (01 02 03 04 05 06 07 08 09 0b 0c 0d 0e 0f 10
             11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f));
  srand; # needed only for perl < 5.004
  return "%$hexctrlchar[rand(30)]%$hexctrlchar[rand(30)]%$hexctrlchar[rand(30)]%$hexctrlchar[rand(30)]"; # bugfix: was 31

3 in bin/view, in main, just below the second if( $topicExists ) {, replace the line:

        $tmpl =~ s/Edit/<A href=\"$scriptUrlPath\/edit\/Codev\/RefreshEditPage\"><B>Edit<\/B><\/A>/go; 
by the 3 lines:
        #  Random URL: to avoid browser cache, but not losing edits on back
        my $randurl = &wiki::randomURL();
        $tmpl =~ s/Edit/<A href=\"$scriptUrlPath\/edit\/Codev\/RefreshEditPage|$randurl\"><B>Edit<\/B><\/A>/go; 

These whole modfications are summarized in the attached patch PatchForExpiresFinal.txt to stable version TWiki20001201.zip

WARNING: you also must apply the FixedScriptUrlPath fix, but I advise you to, as it will solve also other problems, mainly in registration.
-- ColasNahaboo - 20 Apr 2001

I think that a better solution would be to provide a save and continue editing button on the edit page, or even on the preview page. That way the edit->preview->save->edit cycle is not really needed.
-- EdgarBrown - 20 Apr 2001

Mmm... that will not solve the incoherence problem (coming back to edit will make the browser load the old buffer contents as for it the URL is the same), and moreover you will now have pages saved in mid-editing state, that may be unpleasant for people reading them at the same time...
-- ColasNahaboo - 21 Apr 2001

I haven't actually seen the incoherence problem, I'm guessing it must be a browser dependant issue (we are mostly using Netscape Communicator 4.7 under Unix), so we haven't seen the need for this fix (I don't see any caching of the edit pages) [nb: I just did it with this topic, to find a WikiName reference].

I just re-read the topic thread, and I realized that this was already covered, it's just a browser setting that nobody in my location is using. If this is included in the TWiki it must be optional. (CN: Why? see below: *)

On the mid-editing state, that would happen anyway, as whenever you are adding a long text, you might want to go through that cycle to avoid a browser crash from taking all your work with it. Of course, I see your point, having such a button would just make it too easy, and thus more frequent.

This probably should be another use for our new TWiki GenericMetaDataStoreForTopics facility.
-- EdgarBrown - 21 Apr 2001

* The problem is that everything worked fine for me (opera/linux), but a lot of people had problems, and mostly novices, be it on IE, netscape, windows, unix... it depended on browser settings and windows internet settings. Leaving the current situation would have made the group reject TWiki (to be useful a whole group must be confident with TWiki) My solution works perfectly in ALL cases, without any bad side effect, why not making it the default?

-- ColasNahaboo - 23 Apr 2001

Bugfix: in my patch on the wiki page replaced 31 by 30... (the attachment was OK) -- ColasNahaboo - 24 Apr 2001

For TWiki version Sep 2001

To patch the new Sep 2001 version to use unique URLs for editing for avoiding all caching issues:

In file bin/view, replace the line containing

by the 3 lines:

   #  Random URL: to avoid browser cache, but not losing edits on back
    my $randurl = &randomURL();
    $tmpl =~ s/%EDITTOPIC%/<a href=\"$scriptUrlPath\/edit%SCRIPTSUFFIX%/%WEB%\/%TOPIC%|$randurl\">&lt;b>Edit&lt;\/b>&lt;\/a>/go;
And, add to the file (towards the end for instance) the function:
## Random URL:
# returns 4 random bytes in 0x01-0x1f range in %xx form
# =========================
sub randomURL
  my (@hc) = (qw (01 02 03 04 05 06 07 08 09 0b 0c 0d 0e 0f 10
                  11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f));
  #  srand; # uncomment only for perl < 5.004
  return "%$hc[rand(30)]%$hc[rand(30)]%$hc[rand(30)]%$hc[rand(30)]";

The trick is that the addition to the URL is comprised of characters (| and %xx) removed by the $securityFilter, so that TWiki sees the right topic name.

-- ColasNahaboo - 23 Oct 2001

For some discussion of this issue, and which browsers are affected, see Support.BrowserIssues.

-- RichardDonkin - 23 Oct 2001

To anyone using the code on this page - %-variables are being expanded, so the code is being broken by the VerbatimExpandsVariables bug (which I thought was fixed), so Edit the page to get hold of the right code.

Anyway - I have implemented this on the March beta (instructions for Sept 2001 work OK, btw), and it does help, i.e. ensures that the second edit in a session gets the latest data from the server. For some reason, IE5 always seemed to get this right anyway, but now Opera works a lot better, for example. I've tested with IE 5.01, Opera 5.12 for Windows, and Mozilla 0.9.5 for Windows.

Can the CoreTeam have a look at including this as standard, as it's quite a significant improvement for browsers such as Opera that cache aggressively? I have reset the bug status to BugAssigned since I understand that the CoreTeam prefer to set these bugs to fixed when they are in the main code, not just in a patch.

This change doesn't, unfortunately, solve the BackFromPreviewLosesText problem - see that page for more discussion.

-- RichardDonkin - 28 Oct 2001

This is a nice idea (Random stuff on the end) but may be unnecessary; I believe that if you just include a question mark on the end (as if for a cgi variable assignment) then all browsers are supposed to reload the page, at least MSIE used to. That is,


will always reload the page.

-- TWikiGuest - 03 Jan 2002

Hi TWikiGuest - please create a userid and log on, so we know who you are... Also, the convention is to put comments at the bottom of pages in TWiki, so I've moved your comment smile

As for suffixing '?' only - this does not work on Opera, which caches aggressively and I believe would use the cached version of a page URL. In fact, I just tested it, so the original RefreshEditPage trick is needed with Opera.

-- RichardDonkin - 04 Jan 2002

The simplest approach IMO would be to simply do this : change the edit URL from (using this page as an example!) :


This works with no major changes to the codebase - just one line in all likelyhood - but enforces the necessary "make this page look cacheable". If this is insufficient, why not simply extend it to:

I'll grab opera & test it on this machine...

After experimenting it turns out that all that is needed is just a question mark - for Opera 6 (tested in SandBox29 ) - for the tests I performed there. However it operates badly in regard to POST url cgi's (which is poor to say the least) and as a result I'd suggest changing the URL format for all URLs which shouldn't be cached from this:

  • http://twiki.org/<script url path>/<action>/<web>/<Topic>

To this:

  • http://twiki.org/<script url path>/<action>/<web>/?topic=<Topic>

From my tests on SandBox29 using Opera 6 this seems to be sufficient to resolve the problems seen.

I'll add a small patch to my code base to do this now.

-- MichaelSparks - 05 Jan 2002

Interesting - I didn't actually modify TWiki to test the '?' suffix idea, but simply added '?' manually to a 'view' URL in TWiki. When I re-entered this, it was clear that there was no network interaction going on the 2nd and 3rd time - so I can't see how this could work. However, perhaps my test was missing something...

UPDATE: I just tested SandBox29, using the '?'-suffixed URL (Test URL 1), and Opera 5.12 - the browser did indeed cache when I used this Edit URL for the second time, so I'm afraid that a single '?' did not fix this problem. My cache settings were, under Check Modified, to have Documents, Images and Other set to 0 days, 10 hours, 0 minutes (i.e. my normal settings, since Opera doesn't have a 'check once per session' option. Perhaps you have 'Always check' somewhere here, causing Opera not to cache when using this URL?

Given that the existing RefreshEditPage patch works fine, I would suggest we just use this unless there are significant objections. Time of day should also work, and may be more aesthetically acceptable, if that's the problem with the random URL suffix. The chance of selecting the same random suffix as used earlier in the session is very low (each suffix is derived from a random number selected from about 800,000 possibilities, i.e. 30**4), but if this is a concern, TOD would be the way to go.

-- RichardDonkin - 06 Jan 2002

I just noticed that Mozilla (0.9.7, but probably any version, and hence Netscape 6) has this problem as well. So it would be well worth fixing this if TWiki is to make headway with Mozilla, Netscape or Opera users.

Also, for a usability improvement only (doesn't solve this problem but similar ideas have been discussed here), why not put the Save and Preview buttons both on the Edit page? This is what OpenWiki does, and it's very usable - it's clear you can Preview if you want to, and obvious to newbies that this is an option, but Save is the most common option for more expert users.

-- RichardDonkin - 08 Jan 2002

I just tried out SandBox29 with Opera 6.0 for Windows and found just the '?' being present worked, Opera did cache without the '?'. My cache settings were, under Check Modified, to have Documents, Images and Other set to 0 days, 5 hours, 0 minutes (i.e. as it came).

I also tried Netscape 6 and it worked fine - this is with cache set to automatic. Richard, are you sure '?' didn't work for you?

-- JohnTalintyre - 15 Jan 2002

Yes, I just re-tested with Opera 5.12 on Windows:

  1. Loaded the main SandBox29
  2. Clicked the Test URL 0, i.e. Edit with no '?', then hit Back
  3. Clicked the Test URL 1, i.e. Edit with '?' - data is seen on network interface, i.e. not cached
  4. Typed Return after the URL (in the URL entry bar) in this Edit page (same URL as step 3) to re-load it again (simulating 2nd edit in session) - data is not seen on network interface, i.e. was cached

Try this and let me know if you get the same results.

-- RichardDonkin - 15 Jan 2002

Same test works for me in Opera 6 i.e. doesn't use cache. But, I guess the point is that the ? mark along doesn't always work ?TIME=xxx, where xxx is time in seconds sounds (or smaller) good to me. Why go for something random, that will fail occasionally. What do you think?

-- JohnTalintyre - 15 Jan 2002

Using time=NNNN is fine by me, and does avoid the slight chance of collisions - time in seconds also sounds good. It also looks a bit neater without the %-characters of course. I would prefer to just have ?NNNN, to keep it short. One side benefit is that people are less likely to accidentally bookmark or link to the Edit URL, since they should notice the extra stuff on the end.

-- RichardDonkin - 15 Jan 2002

Yes, ?time=NNNN works and is a nice solution indeed! And we can use the %GMTIME% already in TWiki to add it without any addition to the TWiki core. It may consume a bit more CPU that just adding a new var %TIME% that would call the perl var time, but it should be negligible.

Thus the patch becomes: to bin/view change the line 219 from:

        if( $topicExists ) {
            $tmpl =~ s/%EDITTOPIC%/<a href=\"$scriptUrlPath\/edit%SCRIPTSUFFIX%\/%WEB%\/%TOPIC%\"><b>Edit<\/b><</a>/go;
            # remove the NOINDEX meta tag
        if( $topicExists ) {
            $tmpl =~ s/%EDITTOPIC%/<a href=\"$scriptUrlPath\/edit%SCRIPTSUFFIX%\/%WEB%\/%TOPIC%?time=%GMTIME{\"\$mo\$day\$hours\$minutes\$seconds\"}%\"><b>Edit<\/b><</a>/go;
            # remove the NOINDEX meta tag

-- ColasNahaboo - 03 Mar 2002

A slightly more efficient variant. in bin/view towards line 219 apply the changes: (add the green code)

        if( $topicExists ) {
            my( $sec, $min, $hour, $day, $mon, $year ) = gmtime( time() );
            my $timestring = sprintf("%.2u%.2u%.2u%.2u%.2u",$mon+1,$day,$hour,$min,$sec);
            $tmpl =~ s/%EDITTOPIC%/<a href=\"$scriptUrlPath\/edit%SCRIPTSUFFIX%\/%WEB%\/%TOPIC%\?time=$timestring\"><b>Edit<\/b><</a>/go;
            # remove the NOINDEX meta tag

-- ColasNahaboo - 18 Mar 2002

Nice simplification - but how about an even simpler patch? This just uses the number of seconds since 1970 directly, which is the same length of time string in the URL (10 digits at present), e.g. ?time=1016478345. We could also just use ?t=NNNN - the fact that it's time is irrelevant and perhaps confusing; it is just an always-changing value.

        if( $topicExists ) {
            my $timestring = time();
            $tmpl =~ s/%EDITTOPIC%/<a href=\"$scriptUrlPath\/edit%SCRIPTSUFFIX%\/%WEB%\/%TOPIC%\?time=$timestring\"><b>Edit<\/b><</a>/go;
            # remove the NOINDEX meta tag

If you agree this is OK, I'm hoping to commit this to CVS quite soon, since this is a bug fix.

-- RichardDonkin - 18 Mar 2002

It is OK. I guess having a humanly significant string is of no importance.

-- ColasNahaboo - 18 Mar 2002

I've committed this to TWikiAlphaRelease as part of fix for BackFromPreviewLosesText - please give this a try, either from CVS or from the patch files on that page. This should make OperaBrowser a lot more usable (tested with Opera 5.12).

-- RichardDonkin - 21 Mar 2002

This works well but does not cover all cases. Edit can be invoked by other means then the Edit link, for example in More to set a new topic parent and in a user generated form that prefills form fields before creating a topic.

-- PeterThoeny - 22 Mar 2002

Good point - we can cover the More page's links quite easily, so I'll do that.

I don't think we can do much about user-generated forms, other than to recommend that they do something similar if this matters to them - this can be done by suffixing the edit URL (in a template or a TWiki page) with ColasNahaboo's suggestion above:

?t=% GMTIME{\"\$mo\$day\$hours\$minutes\$seconds\"}%

(The actual value of the t parameter is unimportant as long as it is based on time in seconds).

The form case is only really important if it's possible that two uses of a form in the same browser session will generate the same Edit URL - seems a bit unlikely to me (I think most forms will be to generate new pages using a certain template), so I'm not sure if the form case needs addressing.

Some other places where edit is referenced are:

$ grep -l edit%SC *

The cleanest solution would be if templates used %EDITTOPIC% and a single TWiki.pm routine is called from various scripts to do this substitution. Non-core templates may of course refer to edit directly, but it's to their advantage to use %EDITTOPIC%.

-- RichardDonkin - 22 Mar 2002

Yes, but I would advise making EDITTOPIC just the URL, not the whole <a href...= tag. Currently it is impossible to use it with skins having an edit icon...

-- ColasNahaboo - 22 Mar 2002

I've implemented an %EDITURL% variable in the latest TWikiAlphaRelease - this was required in any case for some TWiki templates, i.e. changeform.tmpl, oopslocked.tmpl, oopsmore.tmpl. The fix in TWiki.pm is down to one line now...

User-coded forms are not covered by this bug fix - however, the user can just code this into the form:


This now covers all the cases of a button or link leading to the Edit page. There's no patch because of the number of files involved, see CVS:bin/view and so on (spot the new InterWikis link smile ...)

Let me know how this works for you in KoalaSkin.

-- RichardDonkin - 29 Mar 2002

An %EDITURL% covers most cases. However, in my case have I have an Edit link with an icon. Disabling the edit link in some states is not provided by EDITURL. Something else is needed, like having a %EDITLINK% construct to allow writing in the skin:

   %EDITLINK{enabled="<a href=%EDITURL%><img src=my_icon.gif>Edit</a>" disabled="<img src=my_icon_greyed.gif><strike>Edit</strike>"}%
-- ColasNahaboo - 30 Mar 2002

This sounds reasonable - however, I think there are more states, e.g. the code in view currently generates different link text for Create and Edit. Once we've identified all the states required in templates, I'm happy to code the EDITLINK var (or maybe just EDITTOPIC with parameters, like GMTIME).

-- RichardDonkin - 30 Mar 2002

Fix is now implemented on TWiki.org - still needs some more work on state-dependent Edit links. Hopefully Colas can provide some feedback!

-- RichardDonkin - 05 Apr 2002

I'll take a look at it. In the meantime, for people wanting to install the KoalaSkin, I have pacaked a ready-to apply pacth for the Dec 2001 release: RefreshEditView.patch: patch to bin/view, as of end of Mar 2002, v1, summarizing the long discussion on this topic.

-- ColasNahaboo - 17 Jun 2002

TigerSkin had this same problem. I've added a patch that adds the time count to the edit link on view.tiger.tmpl. I've attached it there.

-- DavisWFrank - 19 Jul 2002

What specifically is still needed to bring this BeijingRelease feature status up from 90% specification, 80 % implementation and 0% documentation?

-- GrantBow - 09 Jan 2003

The feature as it is now works fine, it's just that the more advanced version of the feature, needed for skins that use dynamically varying button images depending on the edit state (see comment of 30 Mar 2002), was not coded. Since this only affects a few skins, and can be coded around at the skin level (IMO), I think we can say this feature is closed and spin off the advanced bit into RefreshEditPageAdvanced. Hence I have set this to BugResolved.

Implementation should therefore be 100%. Docs are only required for skin developers - the administrator level docs are already in BrowserIssues, which needs to migrate to TWiki:TWiki with some cleanup, as for BackFromPreviewLosesText which is a similar issue.

-- RichardDonkin - 10 Jan 2003

So it looks like just documentation left and there's overlap with BackFromPreviewLosesText, great!

-- GrantBow - 28 Jan 2003

Category: TWikiPatches
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch RefreshEditView.patch r1 manage 1.0 K 2002-06-17 - 15:32 ColasNahaboo patch to bin/view, as of end of Mar 2002, v1
Edit | Attach | Watch | Print version | History: r53 < r52 < r51 < r50 < r49 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r53 - 2005-02-15 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.