(Reposted from mediawiki-l due to zero responses.)
I've been adding custom tools to the WikiEditor toolbar (MW 1.17.0 version) and am running into difficulty with browser caching.
When I do something simple, such as adding a button or changing text in a dialog, the change doesn't take effect in my browser due to caching. Even if I hard-refresh (ctrl-F5), the changes do not appear. I have to delete my browser's cached content (e.g., in Firefox, Tools / Options / Advanced / Network / "Clear Now") to see the change. That seems extreme: a browser refresh or hard-refresh ought to be sufficient, right? Or ideally, no refresh at all.
This is in Firefox 7.1, Firefox 3.6, and IE8.
For example, I created a new dialog:
$('#wpTextbox1') .wikiEditor('addModule', { 'dialogs': { 'mytool-module': { title: "My title", id: 'mytool', html: function() { return '<p>foo bar</p>'; }, ...
which is launched from a button:
$('#wpTextbox1') .wikiEditor('addToToolbar', { 'section': 'main', 'group': 'insert', 'tools': { 'mytool': { 'label': 'my label', 'type': 'button', 'icon': mypath, 'action': { 'type': 'dialog', 'module': 'mytool-module' } } } } );
Now if I modify the HTML of the dialog to be "foo bar BLAT" instead of "foo bar", I still see "foo bar" until I clear the browser cache.
However, I can change other parts (say, the button label) without this caching happening.
Is there something else special I should be doing to avoid this level of heavy caching?
Thanks, DanB
On Mon, Oct 17, 2011 at 4:26 PM, Daniel Barrett [email protected] wrote:
(Reposted from mediawiki-l due to zero responses.)
I've been adding custom tools to the WikiEditor toolbar (MW 1.17.0 version) and am running into difficulty with browser caching.
When I do something simple, such as adding a button or changing text in a dialog, the change doesn't take effect in my browser due to caching. Even if I hard-refresh (ctrl-F5), the changes do not appear. I have to delete my browser's cached content (e.g., in Firefox, Tools / Options / Advanced / Network / "Clear Now") to see the change. That seems extreme: a browser refresh or hard-refresh ought to be sufficient, right? Or ideally, no refresh at all.
So.... where's your code being loaded from? Site or use JS pages? Some literal JS files output from an extension? Something else? Can you see it being loaded incorrectly from something cached? Did you check in Firebug or WebKit's developer tools or IE's developer tools to see what the response from the server is?
-- brion
Brion asked:
So.... where's your code being loaded from? Site or use JS pages? Some literal JS files output from an extension? Something else?
From a physical JS file (e.g., myfile.js) handed to ResourceLoader by my extension:
$wgResourceModules["vp.wiki.editor.edittools"] = array( 'scripts' => array( 'js/myfile.js, ), 'localBasePath' => dirname(__FILE__), 'remoteExtPath' => 'MyExtension', );
Can you see it being loaded incorrectly from something cached?
I just observed that the value doesn't change -- even after ctrl-F5 -- unless I clear the browser cache (Tools / Options / Advanced / Network / "Clear Now" in Firefox). This was true in IE and Chrome too.
Did you check in Firebug or WebKit's developer tools or IE's developer tools to see what the response from the server is?
I am running Firebug but didn't check this specifically with it -- actually, debugging WikiEditor is really difficult because so many of its toolbar objects (buttons, menus, etc.) are defined anonymously with wikiEditor('addToToolbar', {...anonymous stuff...}), so I have a lot of trouble locating these objects in the DOM. Any tips? Is there a simple $('#wpTextBox1')... syntax to reach the toolbar buttons etc.?
DanB
On Tue, Oct 18, 2011 at 4:22 PM, Daniel Barrett [email protected] wrote:
Brion asked:
So.... where's your code being loaded from? Site or use JS pages? Some literal JS files output from an extension? Something else?
From a physical JS file (e.g., myfile.js) handed to ResourceLoader by my extension:
$wgResourceModules["vp.wiki.editor.edittools"] = array( 'scripts' => array( 'js/myfile.js, ), 'localBasePath' => dirname(__FILE__), 'remoteExtPath' => 'MyExtension', );
Can you see it being loaded incorrectly from something cached?
I just observed that the value doesn't change -- even after ctrl-F5 -- unless I clear the browser cache (Tools / Options / Advanced / Network / "Clear Now" in Firefox). This was true in IE and Chrome too.
This is probably a ResourceLoader thing, then, not directly related to WikiEditor. Please try waiting 5-10 minutes for the cached version of the startup module (the request with &modules=startup) to expire (it has s-maxage=300, max-age=300), then RL should request your module with an updated timestamp and that should give you the new version. Also, verify that the filesystem timestamp of the file has changed after you updated it, because that's what RL uses to determine whether a file has changed.
Roan
Roan writes:
This is probably a ResourceLoader thing, then, not directly related to WikiEditor. Please try waiting 5-10 minutes for the cached version of the startup module (the request with &modules=startup) to expire (it has s-maxage=300, max-age=300), then RL should request your module with an updated timestamp and that should give you the new version. Also, verify that the filesystem timestamp of the file has changed after you updated it, because that's what RL uses to determine whether a file has changed.
Thanks. Below are the HTTP headers for the "modules=startup" load. I waited 30 minutes after changing the JavaScript file but the change is still not appearing in WikiEditor, even after browser refreshes. I also confirmed that the file timestamp has indeed changed. Any other ideas?
http://myhost.net/w/load.php?debug=false&lang=en&modules=startup&...
GET /w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&* HTTP/1.1 Host: myhost.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Accept: */* Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Referer: http://myhost.net/w/index.php?title=Temp:Test&action=edit&redlink=1 Cookie: autoloadapplet=1; killoptions=1; wikidb_vpw_office_id=2; vector-nav-p-tb=true; _pk_id.3.07be=89b57d07f8d247a6.1318020769.20.1319123488.1318951711.; edittoolscharsubset=0; wikiEditor-0-booklet-help-page=format; wikidb_vpw__session=i0avdgi2p9fn7g0mgosjenftq3; wikiEditor-0-toolbar-section=software; _pk_ses.3.07be=* If-Modified-Since: Thu, 20 Oct 2011 14:52:51 GMT Cache-Control: max-age=0
HTTP/1.1 200 OK Date: Thu, 20 Oct 2011 15:14:55 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.3.3 Last-Modified: Thu, 20 Oct 2011 14:52:51 GMT Cache-Control: public, max-age=300, s-maxage=300 Expires: Thu, 20 Oct 2011 15:19:55 GMT Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 3232 Connection: close Content-Type: text/javascript; charset=utf-8
Hmmm... after about 60 minutes, the change showed up (after a hard refresh) in WikiEditor. Any idea why it took so long?
Something really weird is going on with caching and ResourceLoader/WikiEditor.
Originally my JavaScript file (loaded via ResourceLoader) emitted the string "A". I changed it to "B" and an hour later, the "B" became visible. Then I changed it to "C", refreshed my browser, and the string "A" appeared again!!
Any ideas? Thanks, DanB
* Daniel Barrett [email protected] [Mon, 17 Oct 2011 21:26:19 +0000]:
(Reposted from mediawiki-l due to zero responses.)
I've been adding custom tools to the WikiEditor toolbar (MW 1.17.0 version) and am running into difficulty with browser caching.
When I do something simple, such as adding a button or changing text
in
a dialog, the change doesn't take effect in my browser due to caching. Even if I hard-refresh (ctrl-F5), the changes do not appear. I have to delete my browser's cached content (e.g., in Firefox, Tools / Options
/
Advanced / Network / "Clear Now") to see the change. That seems
extreme:
a browser refresh or hard-refresh ought to be sufficient, right? Or ideally, no refresh at all.
This is in Firefox 7.1, Firefox 3.6, and IE8.
For example, I created a new dialog:
$('#wpTextbox1') .wikiEditor('addModule', { 'dialogs': { 'mytool-module': { title: "My title", id: 'mytool', html: function() { return '<p>foo bar</p>'; }, ...
which is launched from a button:
$('#wpTextbox1') .wikiEditor('addToToolbar', { 'section': 'main', 'group': 'insert', 'tools': { 'mytool': { 'label': 'my label', 'type': 'button', 'icon': mypath, 'action': { 'type': 'dialog', 'module': 'mytool-module' } } } } );Now if I modify the HTML of the dialog to be "foo bar BLAT" instead of "foo bar", I still see "foo bar" until I clear the browser cache.
However, I can change other parts (say, the button label) without this caching happening.
Is there something else special I should be doing to avoid this level
of
heavy caching?
For Firefox there is WebDeveloper extension https://addons.mozilla.org/ru/firefox/addon/web-developer/ which has menu to disable browser caching. In IE8 / IE9 there is menu to disable caching when you run debugger via F12.
I must agree with you that modern browsers are caching the content beyond the evil. And Firefox always was a "pioneer" in that. http://support.mozilla.com/ru/questions/806805
They've got it to the point when DOM is properly altered by the script, however different content is displayed (not matched to DOM state):
"With old versions of Firefox it was possible to fix aggressive client-side caching by restoring of the form values programmatically in Javascript body.onload handler. With FF4 now this does not work. I set selected option values, these are properly stored in DOM tree (according to Firebug inspector), however visual display of select/option is not updated. This is a plain bug, imo."
Dmitriy
For Firefox there is WebDeveloper extension https://addons.mozilla.org/ru/firefox/addon/web-developer/ which has menu to disable browser caching. In IE8 / IE9 there is menu to disable caching when you run debugger via F12.
That's true for me, while developing.... but if I change the WikiEditor toolbar, my 3000 users won't see the change.
I must agree with you that modern browsers are caching the content beyond the evil...
Maybe WikiEditor is doing something special (or not doing something) for the caching to be this aggressive? Thousands of other web sites will properly update if you do a ctrl-F5 (hard refresh). Many MediaWiki extensions do too. But WikiEditor does not: you have to manually erase the browser cache, not only in Firefox but also in IE and Chrome.
DanB
Dmitriy Sintsov wrote:
For Firefox there is WebDeveloper extension https://addons.mozilla.org/ru/firefox/addon/web-developer/ which has menu to disable browser caching. In IE8 / IE9 there is menu to disable caching when you run debugger via F12.
I don't seem to have that option? In which menu do you have it? I don't see it in the 'disable' menu...
On 18.10.2011 19:33, Platonides wrote:
Dmitriy Sintsov wrote:
For Firefox there is WebDeveloper extension https://addons.mozilla.org/ru/firefox/addon/web-developer/ which has menu to disable browser caching. In IE8 / IE9 there is menu to disable caching when you run debugger via F12.
I don't seem to have that option? In which menu do you have it? I don't see it in the 'disable' menu...
I have Disable / Disable cache submenu. However it does not disable the notorious bfcache. There is no simple way to disable it, maybe something really specific like elevating privileges - I didn't even try because it would be very non-standard, if ever possible. Dmitriy