Item5628: it would be useful if there was a version check in the wysiwyg JS
Priority: Enhancement
Current State: Closed
Released In: 1.0.6, 1.1.0
Target Release: patch
I just upgraded wysiwygPlugin, and then hit edit on a topic. the browser obviously cached the js, as I was then presented with a pile of html escaped mess that would scare most users.
full refresh fixed it..
so the freature suggestion is to have a version comparison in the js, that will tell the user if there is a problem - in this case the on the wise format changed, and the cached js was not informing the user.
for extra credit, make the js force reload, or expire the cached version, or, something magical
--
TWiki:Main/SvenDowideit - 14 May 2008
Good idea. Regraded as enhncement.
--
CrawfordCurrie - 04 Aug 2008
I guess the simplest thing is just that the HTML files call not the javasript file directly, but with the version in parameter, e.g.
- instead of
http://foswiki.org/pub/System/JavascriptFiles/foswikilib.js
- call
http://foswiki.org/pub/System/JavascriptFiles/foswikilib.js?v=567
this will get the same file but will force a cache clear on a new version by incrementing the v= parameter in the template files...
A cleaner but more involved solution could be to use a javascript optimizser "compiling" all the .js in one file that will have the version nukber in its name. but then you would have to clean up old versions after some time.
--
ColasNahaboo - 22 May 2009
TinyMCEPlugin adds the links to its own .js files in its
beforeEditHandler
.
Thus, the plugin could URL-encode the
TinyMCEPlugin.pm
$VERSION
and appended that to the .js links, like Colas suggested.
It is not necessary to put version numbers in the templates to address the specific problem that Sven described.
However, similar kinds of problems could occur if the .js files referenced from the templates (such as the one mentioned by Colas) are modified. We still need a general solution to this problem (such as Colas' "compiling" suggestion).
--
MichaelTempest - 30 May 2009