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.
Created attachment 31514 [details] [review] 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
Created attachment 31547 [details] [review] [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
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-querystring/ 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.
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.
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.
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.
(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
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.
Created attachment 33287 [details] [review] 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
Alternative patch including Apache rewrite rules attached.
Hold off on testing.. my RewriteRule needs some more work ;)
Scratch that.. it was just my gitified setup confusing me ;).. Go forth and test ;)
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 :)
Created attachment 33288 [details] [review] 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.
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'
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..
Created attachment 33295 [details] [review] 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
Created attachment 33296 [details] [review] 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
Created attachment 33297 [details] [review] 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.
(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.
Created attachment 33315 [details] [review] Bug 12904 [Followup] - Catch remaining JS files
I'm pretty sure I've caught all css and js now.. lots of regex fun... not.
Created attachment 33317 [details] [review] 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
Created attachment 33318 [details] [review] 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.
Created attachment 33319 [details] [review] 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
Created attachment 33320 [details] [review] 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.
Created attachment 33321 [details] [review] Bug 12904 [Followup] - Catch remaining JS files
Created attachment 33323 [details] [review] 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
Created attachment 33324 [details] [review] 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.
Created attachment 33325 [details] [review] 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
Created attachment 33326 [details] [review] 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.
Created attachment 33327 [details] [review] Bug 12904 [Followup] - Catch remaining JS files
Created attachment 33328 [details] [review] Bug 12904 [Followup] - Add to Intranet for Dev Install I managed to miss the intranet vhost directive first time around..
Hmm.. not sure why this got marked 'In Discussion', setting back to 'Needs Signoff'
Comment on attachment 31547 [details] [review] [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.
What a great idea!
Doesn't apply. I'd *really* like to sign off on this. Martin, can you rebase? Thanks!
Created attachment 48735 [details] [review] 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
Created attachment 48736 [details] [review] 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.
Created attachment 48737 [details] [review] 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
Created attachment 48738 [details] [review] 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.
Created attachment 48739 [details] [review] Bug 12904 [Followup] - Catch remaining JS files
Created attachment 48740 [details] [review] Bug 12904 [Followup] - Add to Intranet for Dev Install I managed to miss the intranet vhost directive first time around..
Created attachment 48741 [details] [review] Bug 12904: Update new occurrences of .js|.css This has been generated using the script attached to the bug report.
Patches rebased (it was a nightmare...)
Created attachment 48742 [details] script to update tt & inc files
(In reply to Jonathan Druart from comment #46) > Created attachment 48742 [details] > script to update tt & inc files Usage: perl kv.pl **/*.tt **/*.inc
I tried this, and I see the scripts having version numbers, but they are part of the file name and so they all throw 404s.
Could you confirm you have updated your apache config?
Created attachment 49572 [details] screenshot Tried again with updated Apache config. No 404 anymore, but it does not seem like the files are reloaded. It looks like a redirect to me and the files used are the ones in the cache, see attached screenshot.
Created attachment 54484 [details] [review] 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
Created attachment 54485 [details] [review] Bug 12904 - Update template css and js file references
Created attachment 54488 [details] [review] 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
I'm at a loss. I just rebased and squashed/split all these patches for readability. Everything is working, but the browser continues to indicate it's grabbing cached files even when the filename has changed! At first I thought it was because the rewrite was doing a 301 redirect, so I removed that, and still had the same thing. Next I tried a 307, but again, the same results ( though chrome decided not to cache some files at all with a 307 ). Here is a video demonstration: http://screencast.com/t/JfFonhkWax Martin, Jonathan, any ideas on what is going on? Kyle
Created attachment 54489 [details] [review] Bug 12904 - Update template css and js file references
(In reply to Kyle M Hall from comment #54) > I'm at a loss. I just rebased and squashed/split all these patches for > readability. Everything is working, but the browser continues to indicate > it's grabbing cached files even when the filename has changed! > > At first I thought it was because the rewrite was doing a 301 redirect, so I > removed that, and still had the same thing. Next I tried a 307, but again, > the same results ( though chrome decided not to cache some files at all with > a 307 ). > > Here is a video demonstration: http://screencast.com/t/JfFonhkWax > > Martin, Jonathan, any ideas on what is going on? > > Kyle Using firebug (network tab) that sounds ok for me: (reload mainpage) mainpage_16.0600014.css 301 (moved permanentely) mainpage.css 200 (click on mainpage) nothing # from cached (change version using the interface, so the page reload and will hit some .css and .js files, that's why we are focusing on mainpage.css) (click on mainpage) mainpage_16.0600014.css 301 (moved permanentely) mainpage.css 200
Back to NSO...
Nobody to signoff on this one?
Created attachment 58378 [details] [review] 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
Created attachment 58379 [details] [review] Bug 12904 - Update template css and js file references
Created attachment 58392 [details] [review] Bug 12904 [QA Followup] - Don't send 301 status
Created attachment 58393 [details] [review] 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 Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 58394 [details] [review] Bug 12904 - Update template css and js file references Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 58395 [details] [review] Bug 12904 [QA Followup] - Don't send 301 status Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Nick Clemens from comment #64) > Created attachment 58395 [details] [review] [review] > Bug 12904 [QA Followup] - Don't send 301 status > > Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Can you explain this patch?
Created attachment 60826 [details] [review] 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 Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Created attachment 60827 [details] [review] Bug 12904 - Update template css and js file references Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Created attachment 60830 [details] [review] Bug 12904 [QA Followup] - Don't send 301 status Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Created attachment 60831 [details] [review] Bug 12904 - Add mod_expire to etc/koha-httpd.conf Has a positive effect on page loads for crazy dev-installs as well.
Rebased to master. (In reply to Jonathan Druart from comment #65) > Can you explain this patch? Yes. Without this bad things will happen when caching is used. Our page load times drop at best 2-4 seconds depending on the env we run Koha. Better than plack :) When the Koha-version changes, the urls for all static web-assets dynamically change to point at the new Koha-version. This forces the browser to reload new versions of javascript-code. You cannot really cache static web-content without a way of invalidating the user's cache, because then after version upgrades, some browsers would use old javascript code and bad things would happen.
I came here to QA this, then realised I wrote a bunch of the original code that was eventually rebased. This is still a great thing to have and we've been using it in production in a few places so I'm happy it works. I'll try to find a friendly QAer.
(In reply to Martin Renvoize from comment #71) > I came here to QA this, then realised I wrote a bunch of the original code > that was eventually rebased. > > This is still a great thing to have and we've been using it in production in > a few places so I'm happy it works. > > I'll try to find a friendly QAer. Just QA this plix? PM when you plan to do so. This is a big moving target and it is hard to keep it applying to master. We have a rebased version from two-three weeks ago I guess. No point in wasting time applying it here because it will just get stale. While doing that I can rebase our fork on top of master.
Created attachment 63692 [details] [review] 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 Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 63693 [details] [review] Bug 12904 - Update template css and js file references Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 63694 [details] [review] Bug 12904 [QA Followup] - Don't send 301 status Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 63695 [details] [review] Bug 12904 - Add mod_expire to etc/koha-httpd.conf Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 63696 [details] [review] Bug 12904 [QA Followup] - Look up the Koha version once Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
>For non-package installations, the following rewrite rules will need to be >added to the apache config file: >RewriteRule ^(.*)_(.*).js$ $1.js [R=301,N,L] >RewriteRule ^(.*)_(.*).css$ $1.css [R=301,N,L] Wonder if this might not get lost - would there be a way to automate it? What happens if you don't?
> RewriteRule ^(.*)_(.*).js$ $1.js [R=301,N,L] This rewrite rules are quite large, what about files that already contain an underscore ? I think we should use a more explicit separator like "_kohav" with rewrite : RewriteRule ^(.*)_kohav(.*).js. > +<script type="text/javascript" src="[% interface %]/[% theme %]/js/datatables_[% KOHA_VERSION %].js"></script> The syspref "Version" contains a dot (ie 16.1200037) meaning that files will have 2 dots, ie : ../datatables_16.1200037.js This may be a problem for some web-browsers like IE ?
Created attachment 70830 [details] [review] 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 Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(In reply to Katrin Fischer from comment #78) > > >For non-package installations, the following rewrite rules will need to be >added to the apache config file: > >RewriteRule ^(.*)_(.*).js$ $1.js [R=301,N,L] > >RewriteRule ^(.*)_(.*).css$ $1.css [R=301,N,L] > > Wonder if this might not get lost - would there be a way to automate it? > What happens if you don't? We will have to highlight that in the release notes. People will quickly now that something is wrong if all JS and CSS files return 404 (In reply to Fridolin SOMERS from comment #79) > > RewriteRule ^(.*)_(.*).js$ $1.js [R=301,N,L] > This rewrite rules are quite large, what about files that already contain an > underscore ? > I think we should use a more explicit separator like "_kohav" with rewrite : > RewriteRule ^(.*)_kohav(.*).js. > > > +<script type="text/javascript" src="[% interface %]/[% theme %]/js/datatables_[% KOHA_VERSION %].js"></script> > The syspref "Version" contains a dot (ie 16.1200037) meaning that files will > have 2 dots, ie : > ../datatables_16.1200037.js > This may be a problem for some web-browsers like IE ? I am going to push these patches soon. Developers will have time to catch the issues before 18.05. If someone disagrees with these patches, tell us why.
Created attachment 70831 [details] [review] Bug 12904: (QA follow-up) Don't send 301 status Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 70832 [details] [review] Bug 12904: Add mod_expire to etc/koha-httpd.conf Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 70833 [details] [review] Bug 12904: Force browser to load new javascript files after upgrade This patch has been automatically generated using: perl kv.pl **/*.tt **/*.inc
Created attachment 70834 [details] [review] Bug 12904: Pass KOHA_VERSION in C4::Auth
Created attachment 70835 [details] script to update tt & inc files
Looks good, just small issues: the staff-global.css and reset-fonts-grids.css in intranet are not versioned The staff-global.css needs to be adressed in file koha-tmpl/intranet-tmpl/prog/en/includes/intranetstylesheet.inc reset-fonts-grids.css is using through @import in staff-global.css, but could be leaved as is, it probably never change and I believe it will be removed in the future as it is part of yui library. in opac the opac.css is needs to be addressed in file koha-tmpl/opac-tmpl/bootstrap/en/includes/doc-head-close.inc script.js and enquiry.min.js needs to be addressed in file koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc
(In reply to Josef Moravec from comment #87) > reset-fonts-grids.css is using through @import in staff-global.css, but > could be leaved as is, it probably never change and I believe it will be > removed in the future as it is part of yui library. That is my goal.
(In reply to Owen Leonard from comment #88) > (In reply to Josef Moravec from comment #87) > > > reset-fonts-grids.css is using through @import in staff-global.css, but > > could be leaved as is, it probably never change and I believe it will be > > removed in the future as it is part of yui library. > > That is my goal. Great!
Created attachment 71250 [details] [review] Bug 12904: Fix occurrences not caught by script
Great catches Josef, thanks!
Created attachment 71251 [details] [review] Bug 12904: Apache configuration Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 71252 [details] [review] Bug 12904: Add mod_expire to etc/koha-httpd.conf Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 71253 [details] [review] Bug 12904: Pass KOHA_VERSION in C4::Auth Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 71254 [details] [review] Bug 12904: Force browser to load new javascript files after upgrade This patch has been automatically generated using: perl kv.pl **/*.tt **/*.inc Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Created attachment 71255 [details] [review] Bug 12904: Fix occurrences not caught by script Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
(In reply to Jonathan Druart from comment #90) > Created attachment 71250 [details] [review] [review] > Bug 12904: Fix occurrences not caught by script Thanks for quick reaction! Passed QA. I just fixed the first patch, which was made as fix of apache configuration, which was part of original patch. Now should apply cleanly on current master.
1. Must misc4dev deal with apache *-git.conf files? If so, how? I think we will have to ask devs to add these 2 lines to /etc/koha/apache-shared-*-git.conf 2. <Joubu> 20 RewriteRule ^(.*)_(.*).js$ $1.js [N,L]. <Joubu> [N,L]? <tcohen> it looks like L shouldn't be there? or N? <tcohen> L = Last <tcohen> N = Next <tcohen> using N is very tricky <tcohen> and need to have a perfect understanding of how all defined rules make sense together Does someone know?
Pushed to master for 18.05, thanks to everybody involved!
We should improve the rewrite rule, it fails for few files (for instance editor_plugin.js on admin/branches.pl?op=add_form&branchcode=CPL) Could anyone take a look?
It seems to break other functionality too, like the modal on translating itemtype descriptions: Loading failed for the <script> with source “http://localhost:8081/intranet-tmpl/lib/greybox/gb_scripts.js”. Should we file a separate bug? This is quite a blocker and hinders testing of other functionalities.
(In reply to Katrin Fischer from comment #101) > It seems to break other functionality too, like the modal on translating > itemtype descriptions: Loading failed for the <script> with source > “http://localhost:8081/intranet-tmpl/lib/greybox/gb_scripts.js”. > > Should we file a separate bug? This is quite a blocker and hinders testing > of other functionalities. I confirm this is fixed by bug 20187.
(In reply to Jonathan Druart from comment #98) > <Joubu> [N,L]? > <tcohen> it looks like L shouldn't be there? or N? > <tcohen> L = Last > <tcohen> N = Next > <tcohen> using N is very tricky N,L is wrong imo N would give other rules a chance to make further rewrites looks to me that normally L would be fine
Awesome work all! Enhancement, not backported to stable.
Thanks all, less cache cleaning for users! :D (In reply to Nick Clemens from comment #104) > [...] Enhancement, not backported to stable. Doesn't this fix bugs actually? Anyway, this would be a pain to backport right?
As we've found quite a few issues with it so far and it requires changing your Apache configuration I think it's not a good candidate for backporting right now.
Indeed, that's kind of a non-backward compatible change. So that would be a bad surprise for a minor upgrade. (In reply to Katrin Fischer from comment #106) > [...] it requires changing > your Apache configuration By the way, is this the right place to ask/post an updated Nginx configuration? (or any other web server)
Updated «Text to go in the release notes» with bug 20187
> By the way, is this the right place to ask/post an updated Nginx > configuration? > (or any other web server) I think we don't officially support Nginx and not a lot of people read here apart from the Bug CC, so probably better on the mailing list or in IRC.
Created attachment 71822 [details] [review] Bug 12904: Add KOHA_VERSION to few more .css
(In reply to Jonathan Druart from comment #110) > Created attachment 71822 [details] [review] [review] > Bug 12904: Add KOHA_VERSION to few more .css Pushed to master.
QA tests added: commit 42ce839b1a61e5fef1836b4525bf942c6b53d878 Bug 12904: Add [% KOHA_VERSION %] for .js and .css
Could anyone explain (again) why we choose to append the version to the filename and not in parameter? So basically why: /my/file_[% KOHA_VERSION %].js and not: /my/file.js?version=[% KOHA_VERSION %] Kyle and Martin talked about the two approaches earlier in comments (from comment 4) but I do not understand. Please clarify. It could avoid the rewrite rules.
(In reply to Jonathan Druart from comment #113) > Could anyone explain (again) why we choose to append the version to the > filename and not in parameter? > > So basically why: > /my/file_[% KOHA_VERSION %].js > and not: > /my/file.js?version=[% KOHA_VERSION %] > > Kyle and Martin talked about the two approaches earlier in comments (from > comment 4) but I do not understand. Please clarify. > > It could avoid the rewrite rules. From one of the linked sources: === But which is better: mylogo.1.2.gif or mylogo.gif?v=1.2? To gain the benefit of caching by popular proxies, avoid revving with a querystring and instead rev the filename itself. === I am not sure if passing a version as parameter in a script URL would be good practice. It seems quite uncommon, but I may be wrong?
AFAIK, the reason the former is better then the latter is fairly simple. With the latter ( that is, /my/file.js?version=[% KOHA_VERSION %] ), the file will *never* be cached. It will always be fetched on each page load. Since we would be passing a GET parameter, a modern web browser would assume the contents of the URL may vary based on the parameter, and will assume it shouldn't cache the file. Kyle (In reply to Marcel de Rooy from comment #114) > (In reply to Jonathan Druart from comment #113) > > Could anyone explain (again) why we choose to append the version to the > > filename and not in parameter? > > > > So basically why: > > /my/file_[% KOHA_VERSION %].js > > and not: > > /my/file.js?version=[% KOHA_VERSION %] > > > > Kyle and Martin talked about the two approaches earlier in comments (from > > comment 4) but I do not understand. Please clarify. > > > > It could avoid the rewrite rules. > > From one of the linked sources: > === > But which is better: mylogo.1.2.gif or mylogo.gif?v=1.2? To gain the benefit > of caching by popular proxies, avoid revving with a querystring and instead > rev the filename itself. > === > I am not sure if passing a version as parameter in a script URL would be > good practice. It seems quite uncommon, but I may be wrong?
Ok, make sense! Thanks for the answers.
query parameters don't necessarily bypass the cache. open the network inspector of your browser and check http://b.oha.it/s/test.html the cache is 10 seconds, so if you are fast enough you will see it fetched from the cache (tested on chrome a firefox on linux)