[Bug 12904] New: Force browser to load new javascript files after upgrade
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Bug ID: 12904 Summary: Force browser to load new javascript files after upgrade Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt@gmail.com Reporter: kyle@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 31514 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31514&action=edit Bug 12904 - Force browser to load new javascript files after upgrade A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. Test Plan: 1) Apply this patch 2) Note that all javascript continues to function properly -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de, | |oleonard@myacpl.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Patch complexity|--- |Medium patch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #31514|0 |1 is obsolete| | --- Comment #2 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 31547 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31547&action=edit [SIGNED-OFF] Bug 12904 - Force browser to load new javascript files after upgrade A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. Test Plan: 1) Apply this patch 2) Note that all javascript continues to function properly Signed-off-by: Owen Leonard <oleonard@myacpl.org> More complete test plan to confirm that caching is working correctly: 1) Apply this patch on a new branch based on master. 2) In a separate branch check out a previous version of Koha and go through the installation process on an empty database. 3) After logging into Koha, turn on Firebug's Net panel (or Chrome's Network panel) and turn on the filter for JavaScript files. 4) Clear the browser cache and navigate to a page, for instance Circulation. In Firebug the Net panel should show a status of "200 OK" for all files, indicating that the file was downloaded, not loaded from the cache. In Chrome the "size" column will show a file size if the file was downloaded. 5) Navigate to another page and confirm that scripts are being loaded from the cache: Scripts like jquery.js and jquery-ui.js which are loaded on every page should have a status in the Firebug Net panel of "304 Not Modified." In Chrome the "size" columns should show "from cache." 6) Check out the branch you created for testing this patch. 7) In order to preserve the state of your browser cache for accurate testing, open a different browser from the one you were previously testing with, load Koha, and run through the database update. 8) Return to your original testing browser and navigate to another Koha page. Firebug's Net panel should show that script files are now being downloaded with a "koha_version" query string. These files should have a status of "200 OK" indicating that they are being downloaded, not loaded from the cache. 9) Navigate to another page and conifrm that the new versions of the scripts are being loaded from the cache. To confirm that all affected JavaScripts links are working correctly, test these pages by checking the Firebug Net panel for errors: - Administration -> Currencies and exchange rates (jquery.dataTables.colvis.js) - Tools -> Stage MARC records for import (ajaxfileupload.js) or another page which performs a file upload. - Catalog -> Detail page -> MARC Preview (greybox JS) - Help -> Any help page - Any page which loads DataTables (Circulation in the staff client, for instance, and a title's detail page in the OPAC) - Bonus points if you check the various conditional JS includes controlled by the many OPAC feature preferences -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #3 from Owen Leonard <oleonard@myacpl.org> --- I'm not sure how relevant this is, but running a performance audit from Chrome Developer Tools gives this warning: "Resources with a "?" in the URL are not cached by most proxy caching servers." Digging into that issue led me to this: http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-query... Sounds like there are Apache configuration options, for instance, to rewrite file names for this purpose. I have no idea whether that fits into Koha's upgrade process. I think we should do a general audit on how we handle compression and caching at the server level--preferably by someone who knows more about it than me. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |master -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #4 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I've been thinking about this problem for a few yers now.. though never gotten around to doing much about it. I did at some point start using mod_pagespeed (by google) on a number of our server, but this unfortunately led to other problems which I could not narrow down to anything but this apache module. However, the real piece I wanted was this caching advantage enabled using the following filter: https://developers.google.com/speed/pagespeed/module/filter-cache-extend I'm wondering if we could do somthing similar, either in the Apache config itself, or in perl pre apache. My thought's were to append a version string within the templates (similar to Kyle's approach but within the filename as opposed to a query string) and then add some re-write rules in apache to remove the appended string again. (I got stuck at the apache re-write rules level.. I've never been especially good at them) I did wonder whether we should be appending a hash of the file content as opposed to a versions for our version string.. to enable the detection of customised changes, but this would obviously add to server load too. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- I think the biggest issue with this approach is it's tied to using Apache, right? This solution should work with apache, nginx, or whatever crazy way someone may have Koha up and running. Am I correct? (In reply to Martin Renvoize from comment #4)
I've been thinking about this problem for a few yers now.. though never gotten around to doing much about it.
I did at some point start using mod_pagespeed (by google) on a number of our server, but this unfortunately led to other problems which I could not narrow down to anything but this apache module.
However, the real piece I wanted was this caching advantage enabled using the following filter:
https://developers.google.com/speed/pagespeed/module/filter-cache-extend
I'm wondering if we could do somthing similar, either in the Apache config itself, or in perl pre apache.
My thought's were to append a version string within the templates (similar to Kyle's approach but within the filename as opposed to a query string) and then add some re-write rules in apache to remove the appended string again. (I got stuck at the apache re-write rules level.. I've never been especially good at them) I did wonder whether we should be appending a hash of the file content as opposed to a versions for our version string.. to enable the detection of customised changes, but this would obviously add to server load too.
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #6 from Owen Leonard <oleonard@myacpl.org> --- I set this bug to "In Discussion" when I submitted comment 3, so I would like to keep it "In Discussion" until that point is discussed. I think this is a worthwhile issue to pursue but I would like to hear more comments. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com --- Comment #7 from Mason James <mtj@kohaaloha.com> --- (In reply to Kyle M Hall from comment #5)
I think the biggest issue with this approach is it's tied to using Apache, right?
not quite... mod_pagespeed has modules for both apache and ngnix -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #8 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I wasn't actually suggesting the use of mod_pagespeed itself, but reimplementing one of its features as best we could. In effect kyles patch does indeed do this, only it utilises a query parameter as a posed to appending to the filename itslef; which as Owen quite rightly suggests could mean that our 'static' resources end up never being chached on ocassions which would adversely affect performance. Kyle, your right that my approach of using rewrite rules would be dependant upon some apache\nginx\whatever server specific rules being written. We are doing this already though for some other cases I think so I don't see that as such a binding reason not to implement it in this way. I'll see if I can find some time today to submit an alternative patch just to give people a clue of what I'm talking about. As for upgrade paths.. I have no idea how the packages handle Apache config updates at current... But I imagine the shared config in /etc/koha to be where such rules should exist and as such believe its perfectly possible to update them. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #9 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33287 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33287&action=edit Bug 12904 - Force browser to load new javascript files after upgrade A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. 1) Apply this patch on a new branch based on master. 2) In a separate branch check out a previous version of Koha and go through the installation process on an empty database. 3) After logging into Koha, turn on Firebug's Net panel (or Chrome's Network panel) and turn on the filter for JavaScript files. 4) Clear the browser cache and navigate to a page, for instance Circulation. In Firebug the Net panel should show a status of "200 OK" for all files, indicating that the file was downloaded, not loaded from the cache. In Chrome the "size" column will show a file size if the file was downloaded. 5) Navigate to another page and confirm that scripts are being loaded from the cache: Scripts like jquery.js and jquery-ui.js which are loaded on every page should have a status in the Firebug Net panel of "304 Not Modified." In Chrome the "size" columns should show "from cache." 6) Check out the branch you created for testing this patch. 7) In order to preserve the state of your browser cache for accurate testing, open a different browser from the one you were previously testing with, load Koha, and run through the database update. 8) Return to your original testing browser and navigate to another Koha page. Firebug's Net panel should show that script files are now being downloaded with a "koha_version" query string. These files should have a status of "200 OK" indicating that they are being downloaded, not loaded from the cache. 9) Navigate to another page and conifrm that the new versions of the scripts are being loaded from the cache. To confirm that all affected JavaScripts links are working correctly, test these pages by checking the Firebug Net panel for errors: - Administration -> Currencies and exchange rates (jquery.dataTables.colvis.js) - Tools -> Stage MARC records for import (ajaxfileupload.js) or another page which performs a file upload. - Catalog -> Detail page -> MARC Preview (greybox JS) - Help -> Any help page - Any page which loads DataTables (Circulation in the staff client, for instance, and a title's detail page in the OPAC) - Bonus points if you check the various conditional JS includes controlled by the many OPAC feature preferences -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #10 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Alternative patch including Apache rewrite rules attached. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #11 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Hold off on testing.. my RewriteRule needs some more work ;) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #12 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Scratch that.. it was just my gitified setup confusing me ;).. Go forth and test ;) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #13 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Of course.. we'll need a followup for other static files too (at least css). I'll get to work on that using my method.. and will include upping the cache time for .js and .css files as this patch basically means we're introducing a method for enforced replacement of caches when, and only when, we want them to get updated :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #14 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33288 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33288&action=edit Bug 12904 [Followup] - Increase JS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for javascript files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #15 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Kyle, how did you choose which files to do this for.. it feels like there are instances of js files referred to which you've not accounted for? I discovered this whilst attempting to find all css files fro a similar treatment. I've used the following command to regex all css imports within file in the templates directory and note that many of my results also contained a JS import that hadn't had your treatment applied? grep -r -l "<link rel=\"stylesheet\" type=\"text\/css\" href=\"" * | xargs sed -i 's/\.css"/_[% KOHA_VERSION %].css"/g' -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #16 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Admittedly.. my regex catches a few file we don't wish to update.. but I'm now going through the file manually to remove those.. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #17 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33295 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33295&action=edit Bug 12904 [Followup] - Give same treatment to CSS We should really do this for other static files too, else you'll still get strange results when mismtaches of resource versions happen This patch applies the same logic to CSS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33295|0 |1 is obsolete| | --- Comment #18 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33296 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33296&action=edit Bug 12904 [Followup] - Give same treatment to CSS We should really do this for other static files too, else you'll still get strange results when mismtaches of resource versions happen This patch applies the same logic to CSS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #19 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33297 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33297&action=edit Bug 12904 [Followup] - Increase CSS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for css files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #20 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- (In reply to Martin Renvoize from comment #15)
Kyle, how did you choose which files to do this for.. it feels like there are instances of js files referred to which you've not accounted for?
I discovered this whilst attempting to find all css files fro a similar treatment.
I've used the following command to regex all css imports within file in the templates directory and note that many of my results also contained a JS import that hadn't had your treatment applied?
grep -r -l "<link rel=\"stylesheet\" type=\"text\/css\" href=\"" * | xargs sed -i 's/\.css"/_[% KOHA_VERSION %].css"/g'
Regarding this comment.. I'm even more sure we've missed a few places for the JS's.. We'll definitely need to handle these before applying my follow-up patch that increases JS cache time. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #21 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33315 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33315&action=edit Bug 12904 [Followup] - Catch remaining JS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #22 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- I'm pretty sure I've caught all css and js now.. lots of regex fun... not. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33287|0 |1 is obsolete| | --- Comment #23 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33317 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33317&action=edit Bug 12904 - Force browser to load new javascript files after upgrade A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. 1) Apply this patch on a new branch based on master. 2) In a separate branch check out a previous version of Koha and go through the installation process on an empty database. 3) After logging into Koha, turn on Firebug's Net panel (or Chrome's Network panel) and turn on the filter for JavaScript files. 4) Clear the browser cache and navigate to a page, for instance Circulation. In Firebug the Net panel should show a status of "200 OK" for all files, indicating that the file was downloaded, not loaded from the cache. In Chrome the "size" column will show a file size if the file was downloaded. 5) Navigate to another page and confirm that scripts are being loaded from the cache: Scripts like jquery.js and jquery-ui.js which are loaded on every page should have a status in the Firebug Net panel of "304 Not Modified." In Chrome the "size" columns should show "from cache." 6) Check out the branch you created for testing this patch. 7) In order to preserve the state of your browser cache for accurate testing, open a different browser from the one you were previously testing with, load Koha, and run through the database update. 8) Return to your original testing browser and navigate to another Koha page. Firebug's Net panel should show that script files are now being downloaded with a "koha_version" query string. These files should have a status of "200 OK" indicating that they are being downloaded, not loaded from the cache. 9) Navigate to another page and conifrm that the new versions of the scripts are being loaded from the cache. To confirm that all affected JavaScripts links are working correctly, test these pages by checking the Firebug Net panel for errors: - Administration -> Currencies and exchange rates (jquery.dataTables.colvis.js) - Tools -> Stage MARC records for import (ajaxfileupload.js) or another page which performs a file upload. - Catalog -> Detail page -> MARC Preview (greybox JS) - Help -> Any help page - Any page which loads DataTables (Circulation in the staff client, for instance, and a title's detail page in the OPAC) - Bonus points if you check the various conditional JS includes controlled by the many OPAC feature preferences -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33288|0 |1 is obsolete| | --- Comment #24 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33318 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33318&action=edit Bug 12904 [Followup] - Increase JS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for javascript files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33296|0 |1 is obsolete| | --- Comment #25 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33319 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33319&action=edit Bug 12904 [Followup] - Give same treatment to CSS We should really do this for other static files too, else you'll still get strange results when mismtaches of resource versions happen This patch applies the same logic to CSS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33297|0 |1 is obsolete| | --- Comment #26 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33320 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33320&action=edit Bug 12904 [Followup] - Increase CSS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for css files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33315|0 |1 is obsolete| | --- Comment #27 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33321 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33321&action=edit Bug 12904 [Followup] - Catch remaining JS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33317|0 |1 is obsolete| | --- Comment #28 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33323 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33323&action=edit Bug 12904 - Force browser to load new javascript files after upgrade A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. 1) Apply this patch on a new branch based on master. 2) In a separate branch check out a previous version of Koha and go through the installation process on an empty database. 3) After logging into Koha, turn on Firebug's Net panel (or Chrome's Network panel) and turn on the filter for JavaScript files. 4) Clear the browser cache and navigate to a page, for instance Circulation. In Firebug the Net panel should show a status of "200 OK" for all files, indicating that the file was downloaded, not loaded from the cache. In Chrome the "size" column will show a file size if the file was downloaded. 5) Navigate to another page and confirm that scripts are being loaded from the cache: Scripts like jquery.js and jquery-ui.js which are loaded on every page should have a status in the Firebug Net panel of "304 Not Modified." In Chrome the "size" columns should show "from cache." 6) Check out the branch you created for testing this patch. 7) In order to preserve the state of your browser cache for accurate testing, open a different browser from the one you were previously testing with, load Koha, and run through the database update. 8) Return to your original testing browser and navigate to another Koha page. Firebug's Net panel should show that script files are now being downloaded with a "koha_version" query string. These files should have a status of "200 OK" indicating that they are being downloaded, not loaded from the cache. 9) Navigate to another page and conifrm that the new versions of the scripts are being loaded from the cache. To confirm that all affected JavaScripts links are working correctly, test these pages by checking the Firebug Net panel for errors: - Administration -> Currencies and exchange rates (jquery.dataTables.colvis.js) - Tools -> Stage MARC records for import (ajaxfileupload.js) or another page which performs a file upload. - Catalog -> Detail page -> MARC Preview (greybox JS) - Help -> Any help page - Any page which loads DataTables (Circulation in the staff client, for instance, and a title's detail page in the OPAC) - Bonus points if you check the various conditional JS includes controlled by the many OPAC feature preferences -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33318|0 |1 is obsolete| | --- Comment #29 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33324 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33324&action=edit Bug 12904 [Followup] - Increase JS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for javascript files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33319|0 |1 is obsolete| | --- Comment #30 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33325 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33325&action=edit Bug 12904 [Followup] - Give same treatment to CSS We should really do this for other static files too, else you'll still get strange results when mismtaches of resource versions happen This patch applies the same logic to CSS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33320|0 |1 is obsolete| | --- Comment #31 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33326 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33326&action=edit Bug 12904 [Followup] - Increase CSS Cache Timeout With the addition of a method for explicetly forcing a cache refresh, we should make the sue of much large cache times for such files. This patch increases the ache time for css files from 12 hours to 60 days. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33321|0 |1 is obsolete| | --- Comment #32 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33327 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33327&action=edit Bug 12904 [Followup] - Catch remaining JS files -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 --- Comment #33 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 33328 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33328&action=edit Bug 12904 [Followup] - Add to Intranet for Dev Install I managed to miss the intranet vhost directive first time around.. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #34 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Hmm.. not sure why this got marked 'In Discussion', setting back to 'Needs Signoff' -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #31547|0 |1 is obsolete| | --- Comment #35 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Comment on attachment 31547 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31547 [SIGNED-OFF] Bug 12904 - Force browser to load new javascript files after upgrade Obsoleting the original patch to make applying the current series easier... I would still like to hear others thoughts on this alternative approach however. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti@jns.fi --- Comment #36 from Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> --- What a great idea! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |kyle.m.hall@gmail.com --- Comment #37 from Kyle M Hall <kyle.m.hall@gmail.com> --- Doesn't apply. I'd *really* like to sign off on this. Martin, can you rebase? Thanks! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org