Do you get hit with the ConflictContent page way too often? (The "Oops! Someone modified the page while you were editing it!" page.)

When in a fast & furious flurry of edits and previews all too often I end up too far back in my browsers history and end up reusing an "old" edit window. The root problem here is that Edit.jsp/page=Blah urls are in the browser history and you can "back" into them. (This is a bigger issue for folks who routinely use the "backspace" key to navigate back in history.)

There is a solution to this it involved some very minor mods to the EditContent.jsp (depends on wiki version and template being used actualyl)

  • To the Form add onSubmit="if(doAutoBack) window.history.go(-1);"
  • To the Save and Cancel submit buttons, added: onClick="doAutoBack=true;"
  • To the Preview submit button, added: onClick="doAutoBack=false;"

There are all sorts of way that you can try to acive this effect, but you wind up in browser compatibility/security headache land... Apparently "they" decided that javascript was not allowed to modify the browsers history list (or even read it!

The way this patch works is a bit cheesey but JohnV's been using it for almost a year now on a slightly modded MRG Template and have had no ill effects. Basically what this patch does is submit the form contents, immediatly goes back one step in history then the server response takes you to the page that the edit-submit was for. viola, magic! (but timing sensitive maybe?) One caveat is that you can still navigate forward in your history into the edit window, but I'm willing to live with that as I do not know the keyboard shortcut for navigating forward.

This seemes to work nicely for us; everyone here uses IE, I use Opera occasionally, but it's not really been tested on anyhting besides those. The .go(-1) bit works fine under Netscape according to google and the rest is very basic javascript.

I'm not sure why this shouldn't be made part of the default template, as it is just so darn useful at keeping novices from getting confused with old edits in thier browser history.

An alternate solution to this may simply be to disable page caching. This would force every page view to reload from the server. If you don't have a high load then you can afford the server work. This will ensure that a user's browser view always coresponds with the data model inside the wiki.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-10) was last changed on 29-Apr-2008 20:06 by HarryMetske