Hello.
I tried to update OJS from 3.1.0 to 3.1.1. But there was a problem with assigning a role to the user. Even the site administrator does not have a role and can not add articles. The problem remained even when trying to install this version from scratch.
This problem is observed in different system configurations:
I do have the same problem in my installation.
Hi all,
Hmmm… @1118, do you use the release package or git code? Hmmm… it seems like you did not install everything needed i.e. it seems like you would need to clear cache and do this:
install nodejs if you don’t already have it
npm install
npm run build
S. readme here: GitHub - pkp/ojs: Open Journal Systems is open source software to manage scholarly journals.
I am not sure what everything is needed when using the release package, thus I will tag @NateWr and @asmecher here – is npm install and run build needed when using the release package?
Best,
Bozana
I use the installation package from the official site - https://pkp.sfu.ca/ojs/ojs_download/
If I install version 3.1.0, then everything is fine. But when installing or upgrading to version 3.1.1, this problem occurs
The user roles were changed to use our new ui-library in the new release 3.1.1…
No.
From the screenshot, it appears that the user role list is loading, but no roles are available. If someone who is having the problem could check their PHP error log as well as the browser console for any error messages, I’ll take a look.
hmmm… do I not see well: it seems like ui-library is not in the lib folder in the release package – should this be the case?
EDIT: ah, me crazy, this is all build JS… 
Hi all,
My problem is solved itself. Maybe it was a cache issue.
Now I get all the roles.
best regards,
Very interesting…
When I use the Google Chrome browser, it shows the following errors:
In PHP 5.6.26:
In PHP 7.0.11:
And the same error console for both versions PHP on the tab Submission:
But in the Opera browser this error does not exist. Maybe it was really a cache.
But the error when you can not remove the submitted article remained in this version
I cleared the cache in Google Chrome browser and the problem with the roles disappeared
HI @1118,
If it is working for me (any user) means OJS code should be OK.
I suggest you re-install everything from scratch. Make sure you restore database and file folder from the backup (which was working previously with your old OJS installation).
Also, you increase your Maximum execution time in php setting to atleast 180 seconds.
Best regards,
Hi all,
I wonder if this isn’t caused by the browser caching old Javascript code. Try doing a hard refresh if you encounter this, to see whether that resolves it.
Regards,
Alec Smecher
Public Knowledge Project Team
Maybe OJS could have something like somescript.js?version=3.1.1 to force reload of javascript after upgrades?
Hi @ajnyga,
Good idea – @NateWr, any objection? This would be pretty quick to add to the addJavaScript toolset automatically.
Thanks,
Alec Smecher
Public Knowledge Project Team
No objections. WP does something similar, and I know there has been some chat about this effecting proxy setups, but the consensus seems to be that it is better than not having it, and I think it makes sense for our users.
Another approach is to hash the file itself and append that as a query string. That can be good if we want to bust cache between versions at all.
I confirm. With a simple CTRL + SHIFT + R I was able to see the correct behavior of the new OJS.
I upgrade OJS to 3.1.1-1 two weeks ago, and when I and two editors enter to the submission list, this appears as a blank page, and only fix that with CTRL + SHIFT + R or SHIFT + F5, two of as solve this at the first day and I was thinking that maybe this not will be a problem in a few days because cache will be deleted but even some days after the upgrade one editor have the same issue…
I have fear about upgrade now to 3.1.1-2 because the journal is more active and has authors and reviewers active all day, what is the recommendation to avoid this issue? I can’t explain to all users that they need use CTRL + SHIFT + R
I hope you understand my question 
thanks for all
Hi @t4x0n,
Here’s a diff showing a small change you can make to add a query string with the current version of OJS to every script and style loaded (eg /style.css?v=3.1.1.0). Then when you update OJS, the version will be bumped and browsers will not rely on the cached data:
diff --git a/classes/template/PKPTemplateManager.inc.php b/classes/template/PKPTemplateManager.inc.php
index df01185..5240391 100644
--- a/classes/template/PKPTemplateManager.inc.php
+++ b/classes/template/PKPTemplateManager.inc.php
@@ -1433,6 +1433,9 @@ class PKPTemplateManager extends SmartyBC {
$context = 'frontend';
}
+ $versionDao = DAORegistry::getDAO('VersionDAO');
+ $appVersion = $versionDao->getCurrentVersion()->getVersionString();
+
$stylesheets = $this->getResourcesByContext($this->_styleSheets, $params['context']);
ksort($stylesheets);
@@ -1443,6 +1446,9 @@ class PKPTemplateManager extends SmartyBC {
if (!empty($style['inline'])) {
$output .= '<style type="text/css">' . $style['style'] . '</style>';
} else {
+ if (strpos($style['style'], '?') === false) {
+ $style['style'] .= '?v=' . $appVersion;
+ }
$output .= '<link rel="stylesheet" href="' . $style['style'] . '" type="text/css" />';
}
}
@@ -1465,6 +1471,9 @@ class PKPTemplateManager extends SmartyBC {
$params['context'] = 'frontend';
}
+ $versionDao = DAORegistry::getDAO('VersionDAO');
+ $appVersion = $versionDao->getCurrentVersion()->getVersionString();
+
$scripts = $this->getResourcesByContext($this->_javaScripts, $params['context']);
ksort($scripts);
@@ -1475,6 +1484,9 @@ class PKPTemplateManager extends SmartyBC {
if ($data['inline']) {
$output .= '<script type="text/javascript">' . $data['script'] . '</script>';
} else {
+ if (strpos($data['script'], '?') === false) {
+ $data['script'] .= '?v=' . $appVersion;
+ }
$output .= '<script src="' . $data['script'] . '" type="text/javascript"></script>';
}
}
I’ve assigned the existing issue and highlighted the drawbacks of this approach there.
Thank you very much, this is very helpful!
is not possible to add this change in the milestone OJS 3.1.1-3?
We want to keep that milestone as trim as possible, and limited to major bugs. (A side note: if there are no changes to the JS/CSS in a release, you won’t face any issues with cached files.)