When loading javascript resources, OJS should include a version parameter to avoid problems with browser caching old javascript that will be somewhat incompatible with a new OJS version

I have experienced during a few minor OJS 3.x upgrades that right after an OJS upgrade, several parts of the administration interface will not be populated, even after clearing the template cache in OJS.

Clearing the browser cache has always remedied this issue.

I believe the problem is that sometimes in an upgrade, the php-code changes a bit, and the old javascript responsible for the administration interface (backend) is not up to date with the new php-code. During such occurences I have to email all our journals with information on how to clear the browser cache. Surprisingly, some of the users find it really hard to clear the browser cache even when getting very detailed instructions, also if the caching issue would affect users with the role of authors, reviewers and readers, we’re talking about more than 6000 users who could be affected for only the journals we’re hosting.

I believe it is really easy to avoid this problem altogether. If OJS were to include a OJS-version or script version parameter to the end of the url of the javascript resource, then the browser will understand that this file has been changed, and will load the new javascript resource instead of using the cached resource.

For instance in lib/pkp/classes/template/PKPTemplateManager.inc.php

$baseUrl . ‘/js/build.js’,
‘priority’ => STYLE_SEQUENCE_LATE,
‘contexts’ => array(‘backend’)

change $baseUrl . ‘/js/build.js’, to $baseUrl . ‘/js/build.js?ojs-version=3.1.1-4’,
where obviously you would use a proper php-function or variable to get the actual version.

Or you could insert script version or OJS-version somewhere else, for instance in the addJavaScript method, just making sure it will appear in the source generated from php.

This way, I believe it would be unneccesary for end users to clear their browser cache after an OJS upgrade, only the OJS administrator would have to clear the template cache after the upgrade.

What are your opinions and insights?

Best regards,
Eirik Hanssen
Head engineer
OsloMet University Library

see Add timestamp to CSS and JS files for when they are built · Issue #3340 · pkp/pkp-lib · GitHub

Should be in 3.2

Thank you ajnyga! Good that it’s taken care of in 3.2. Meanwhile I can apply this fix.

yeah, I have been using it in Journal.fi for a while now and seems to work fine.