I have upgraded from OJS 2.4.8 to OJS 3.1.1.4, on a Debian Linux, with php 7.2 (as well as 5.6 but Apache is serving the 7.2 for OJS), mysql 15.1.
Everything went well. I installed oldGregg theme. All good. At one moment I had some problems with something and I erased by mistake all cache folder content.
Now almost all links inside the administration panel are of the form:
##navigation.submissions##
##editor.navigation.issues##
##editor.issues.futureIssues##
##editor.issues.backIssues##
##navigation.settings##
##context.context##
##manager.website##
##manager.workflow##
##manager.distribution##
##navigation.access##
##manager.users##
##manager.roles##
##manager.siteAccessOptions.siteAccessOptions##
##navigation.tools##
##navigation.tools.importExport##
##navigation.tools.statistics##
##navigation.admin##
##context.current##
##common.tasks##0
##navigation.viewFrontend##
administrator
##common.viewProfile##
##user.logOut##
##navigation.submissions##
##dashboard.myQueue##
##common.queue.long.submissionsUnassigned##
##common.queue.long.active##
##navigation.archives##
##help.help##
##common.queue.long.myAssigned##
Also oldGregg links on the frontend look the same.
Then I recreated the subfolders t_cache, t_compile, t_config, _db, made sure the apache user has rights in those folders.
The problem is I canāt get back to the normal links.
Hi @ojspkpuser
The translated message keys are located within xml files of related locale folders. I searched some of these message keys.
For ex;
common.queue.long.myAssigned ā> siteroot/lib/pkp/locale/en_US(or other languages)/submission.xml
editor.navigation.issues ā> siteroot/locale/en_US/locale.xml
If these messages are displayed while using English interface, then you probably deleted these files. So, you should put them back from an install pack.
For other languages, you should check whether the last directories exist for your own locale. If not present, create the missing directory (like tr_TR) and put the same files from en_US directory and translate them manually. If XML files are present, then most likely the message keys are missing in these files. If so, you may add them by using an xml editor.
Regards,
Ugur Kocak
Hi @primozs, thank you for the answer. I forgot to mention. I am using English. It was also the default locale.
Hi @drugurkocak, thank you for all the suggestions. I checked inside siteroot/lib/locale/en_US, and also in siteroot/locale/en_US and all xml files are identical to the ones in the downloaded archive OJS.
I viewed the xml files, and they correctly contain the correct text to show.
What I erased was only the content of the /cache folder.
So I donāt know how to make the locale show correctly.
Hi @ojspkpuser
Then, There are many possibilities in this case. Wrong file permissions, wrong config file settings, etc.
Could you share the URL of your website?
Did you apply upgrade on the live site or on your pc locally?
Since you can log in, you may change the theme to default and look if itās fixed.
Regards,
Ugur
Hi @drugurkocak, Thank you for the response!
This is a testing website for the upgrade. medpharmareports.com
The file permissions are ok, also the file ownership (for the apache daemon).
Changing to the default theme doesn t resolve the issue.
The administrator interface is partially unusable due this phenomenon.
I found now another thread on a similar issue on the forum:
It seems this issue can appear from time to time.
One user cleared some of the caches from the administrator interface, but this is not working in my interface since due to the hash signs some actions are not feasible.
Hi @ojspkpuser
On my local pc, I deleted cache folder and recreated them. Then decreased file permissions to 111 (no read or write permission) then got the same result. So with ftp client, change the permissions of cache and its subfolders to a higher level (may be 755) then please try again, hope this solves.
Regards,
I am thinking maybe when the upgrade was done, possibly the language locale was not correctly upgraded.
The problem is that I can t change at all any locale due to this issue.
Hi @ojspkpuser
I am sorry that I couldnāt help you.
I also experienced a similar problem during upgrade to ojs 3, because our journal site used english and turkish locale, but the english interface was ok.
Since I am not so professional, may be better to stop here. May be OJS team help you.
By the way, oldGregg theme looks very nice, but I faced some weird errors after installed it, and returned back to default theme. For ex; when I click to an article title, a different submission comes.
You can see what I mean by looking at that page; http://upgrade.adlitipbulteni.com/index.php/atb/index
and clicking the title; Parental Alienation - Father as a Rejected Parent http://upgrade.adlitipbulteni.com/index.php/atb/article/view/1125
another article comes. I couldnāt understand the mechanism behind this, because everything is ok with default theme and Health Sciences theme.
Regards,
Hi @drugurkocak
No problem!
Thank you so much for all the help, good intentions, and all the effort you put to try to help me!
Also thank you for warning me about the possible problems with the oldGregg theme!
Indeed it is so surprising another article is opening ā¦
Then I will check it for my website too, and if unstable I will go wit the Health Sciences or the default theme.
Are files being created in the ācacheā directory and the āt_compileā subdirectory within the cache directory? The localization strings most directly relate to the cache files named fc-locale-*.php in the cache directory itself.
Yes there are fc-locale-*.php files in the cache directory.
The t_compile subdirectory contains onlfy*.tpl.php files.files
Do you know where I could modify the MySQL database to install another locale and set it as current? Maybe the English one is somehow not correctly selected.
The inclusion of ro_RO in the installed_locales indicates that Romanian was previously installed, but then disabled within the locales. OJS3 does not currently have Romanian support. Leaving it disabled should not cause any problems.
I donāt see any issues in the data youāve selected from the database.
Warning: Cannot use a scalar value as an array in /var/www/website/lib/pkp/classes/core/DataObject.inc.php on line 133
Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /var/www/website/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 0
Warning: Declaration of CustomHeaderPlugin::register($category, $path) should be compatible with LazyLoadPlugin::register($category, $path, $mainContextId = NULL) in /var/www/website/plugins/generic/customHeader/CustomHeaderPlugin.inc.php on line 0
Notice: Undefined index: en_US in /var/www/website/lib/pkp/classes/context/Context.inc.php on line 273
Warning: Cannot use a scalar value as an array in /var/www/website/lib/pkp/classes/core/DataObject.inc.php on line 133
Warning: Declaration of CustomBlockPlugin::getBlockContext() should be compatible with BlockPlugin::getBlockContext($contextId = NULL) in /var/www/website/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php on line 0
Warning: Declaration of CustomBlockPlugin::getEnabled() should be compatible with BlockPlugin::getEnabled($contextId = NULL) in /var/www/website/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php on line 0
Notice: Only variables should be passed by reference in /var/www/website/plugins/generic/customBlockManager/CustomBlockManagerPlugin.inc.php on line 65
Notice: Only variables should be passed by reference in /var/www/website/plugins/generic/customBlockManager/CustomBlockManagerPlugin.inc.php on line 65
Notice: Only variables should be passed by reference in /var/www/website/plugins/generic/customBlockManager/CustomBlockManagerPlugin.inc.php on line 65
Notice: Only variables should be passed by reference in /var/www/website/plugins/generic/customBlockManager/CustomBlockManagerPlugin.inc.php on line 65
Warning: Cannot use a scalar value as an array in /var/www/website/lib/pkp/classes/core/DataObject.inc.php on line 133