Item5628: it would be useful if there was a version check in the wysiwyg JS

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