My system has OJS 2.4.6 running on
PHP 5.3.2-1
MySQL 5.7.21
Apache 2.4.18
I’m trying to update it to OJS 3 but all the tests I do are wrong.
- I have tried to update it to version 3.0.1 and 3.0.2 in two different tests and after running
“php tools / upgrade.php upgrade” everything ends correctly.
But the system does not work after the two update tests in the browser returns the error in trying to open the initial screen
Fatal error: Call to a member function getUserVar () on a non-object in /home/sp-dgroup/a3/www.um.es/testmigra/ojs_v3.0.2/classes/i18n/AppLocale.inc.php on line 75
- I have also tried updating from OJS 2.4.6 to 3.1.0 and 3.1.0-1 in two different executions starting from the initial one, on the system
PHP 7.0
MySQL 5.7.21
Apache 2.4.18
but after the execution of “php tools / upgrade.php upgrade” it always returns the error
PHP Fatal error: Uncaught Error: Call to a member function getId() on null in /ojs_v3.1.0_1/classes/install/Upgrade.inc.php:1103
Stack trace:
#0 /ojs_v3.1.0_1/lib/pkp/classes/install/Installer.inc.php(415): Upgrade->convertSupplementaryFiles(Object(Upgrade), Array)
#1 /ojs_v3.1.0_1/lib/pkp/classes/install/Installer.inc.php(265): Installer->executeAction(Array)
#2 /ojs_v3.1.0_1/lib/pkp/classes/install/Installer.inc.php(186): Installer->executeInstaller()
#3 /ojs_v3.1.0_1/lib/pkp/classes/cliTool/UpgradeTool.inc.php(88): Installer->execute()
#4 /ojs_v3.1.0_1/lib/pkp/classes/cliTool/UpgradeTool.inc.php(64): UpgradeTool->upgrade()
#5 /ojs_v3.1.0_1/tools/upgrade.php(34): UpgradeTool->execute()
#6 {main}
thrown in /ojs_v3.1.0_1/classes/install/Upgrade.inc.php on line 1103
Could you help me perform a correct update to OJS 3?
Hi @PascualRico,
Is it possible that you have a journal without an enrolled journal manager? In your OJS 2.x (before trying the upgrade), make sure all your journals have at least one journal manager.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
If I had a magazine without a manager but I think that is not the problem since I have made new tests but I get the same results.
I have tried to go from OJS 2.4.6 to 2.4.8_3 and this step is done without problems but when going from 2.4.8_3 to version 3.1.1 and I get the following error in the browser
Fatal error: Uncaught Error: Call to a member function getUserVar() on null in /ojs_v3.1.1/classes/i18n/AppLocale.inc.php:75 Stack trace:
#0 /ojs_v3.1.1/lib/pkp/classes/core/PKPPageRouter.inc.php(128): AppLocale::getLocale()
#1 /ojs_v3.1.1/lib/pkp/classes/core/Dispatcher.inc.php(198): PKPPageRouter->getCacheFilename(Object(Request))
#2 /ojs_v3.1.1/lib/pkp/classes/core/Dispatcher.inc.php(120): Dispatcher->_displayCached(Object(PageRouter), Object(Request))
#3 /ojs_v3.1.1/lib/pkp/classes/core/PKPApplication.inc.php(247): Dispatcher->dispatch(Object(Request))
#4 /ojs_v3.1.1/index.php(68): PKPApplication->execute()
#5 {main} thrown in /ojs_v3.1.1/classes/i18n/AppLocale.inc.php on line 75
Hi @PascualRico,
Do you have any third-party code or extra plugins in your OJS 3.x codebase?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
We have an OJS with more than 60 magazines and if there are many plugins installed
Metadata Plugins
Authorization Plugins
Block Plugins
Citation Format Plugins
Citation Database Connector Plugins
Citation Output Plugins
Citation Extraction Plugins
Gateway Plugins
Generic Plugins
Implicit Authentication Plugins
Import/Export Plugins
OAI Metadata Format Plugins
Payment Plugins
Public Identifier Plugins
Report Plugins
Theme Plugins
I was not responsible for the magazines but I have been tasked with updating OJS to be compatible with the PHP version of our servers. Our servers have been upgraded to PHP version 7 and currently we keep the magazines on the old server with PHP 5.3.2 but it is destined to be turned off as soon as possible.
On whether there is a third-party code, I do not think so, but I can not say for sure.
Should I disable all plugins before upgrading?
Could it be that the PHP version change is too big?
Thanks for your time
Hi @PascualRico,
PHP7 should be fine, and a lot of plugins are included with OJS that should also be fine. When you update the code, do you put the new code in a fresh location or do you extract the OJS package over top of your old version? If the latter, then that could cause incompatible plugin code to be mixed in.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
I have been doing more migration tests, before making the upgrade I have reviewed that:
- I do not have duplicate review_rounds, using the query
SELECT rr.* FROM review_rounds as rr WHERE rr.review_round_id
NOT IN (SELECT MIN(rrr.review_round_id) FROM review_rounds as rrr
GROUP BY rrr.submission_id, rrr.round);
- I do not have sections of articles with null, using the query
SELECT a.article_id FROM articles a LEFT JOIN sections s ON (a.section_id = s.section_id) WHERE s.section_id IS NULL;
- I have at least one manager in each journal
But after launching the upgrade I get the error
PHP Fatal error: Call to a member function getId () on null in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/classes/install/Upgrade.inc.php on line 1002
Specifically, it corresponds to $creatorUserId = $managerUsers->next()-> getId(); of the setFileUploader () function
I have reviewed the execution and contrasted the data with the database and I have the following
when you run
$managerUserGroup = $userGroupDao->getDefaultByRoleId($ journal->getId(),ROLE_ID_MANAGER);
for the JournalID=181 I get that $managerUserGroup=[3411, 3421, 3431]
but when doing
$managerUsers = $userGroupDao->getUsersById($managerUserGroup->getId(), $journal->getId());
for the mangerUserGroup=3411 no row is obtained so when executing
$creatorUserId = $managerUsers->next()->getId(); the Fatal Error error is obtained.
Could you tell me how to correct the error in order to finish the upgrade?
Hi @PascualRico,
When you look in your DB table user_group_settings, the column setting_value, what are those 3411, 3421, 3431 user groups?
Thanks!
Bozana
Hi @PascualRico,
I suspect you have an entry in your roles or section_editors referring to a user_id that doesn’t exist in the users table. I’d suggest removing that entry.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
You were right in your first answer, I had a journal without manager that had not appeared to me in my first search and it is the one that was causing me the error in the update.
The upgrade has finished correctly but I have obtained quite a few messages of the type
PHP Notice: Only variables should be passed by reference in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/lib/adodb/adodb-xmlschema.inc.php on line 267
and many of this type, in which they change the offset and the number of bytes
PHP Notice: unserialize (): Error at offset 222 of 1454 bytes in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/db/DAO.inc.php on line 352
PHP Notice: unserialize (): Error at offset 39 of 213 bytes in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/db/DAO.inc.php on line 352
After the “php tools / upgrade.php upgrade” I have put in the file config.inc.php “installed = On” but the browser returns the following error teniendo
show_stacktrace = On
display_errors = On
deprecation_warnings = On
log_web_service_info = On
Fatal error: Uncaught Error: Call to a member function getUserVar() on null in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/classes/i18n/AppLocale.inc.php:75 Stack trace:
#0 /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/core/PKPPageRouter.inc.php(128): AppLocale::getLocale()
#1 /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/core/Dispatcher.inc.php(198): PKPPageRouter->getCacheFilename(Object(Request))
#2 /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/core/Dispatcher.inc.php(120): Dispatcher->_displayCached(Object(PageRouter), Object(Request))
#3 /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/lib/pkp/classes/core/PKPApplication.inc.php(247): Dispatcher->dispatch(Object(Request))
#4 /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/index.php(68): PKPApplication->execute()
#5 {main} thrown in /home/sp-dgroup/a1/www.um.es/testmigra/ojs_v3.1.1/classes/i18n/AppLocale.inc.php on line 75
Any ideas to see the OJS environment with journals? Could it be due to the previous unserialize() errors?
Hi @asmecher
The problem was that I had put in the configuration file “web_cache = On” and that’s why I was not generating the pages, as soon as I set it to Off, the migration of tests that I made has started to work.
Now I have the problem that I can not get him to take the .css style sheet that is located in public/site/sitestyle.css and the navigator is making the next call
GET http://testmigra.um.es/$$$call$$$/page/page/css?name=stylesheet
getting a
Status Code: 404 Not Found
Hi @PascualRico,
On the unserialize warnings, there are two likely causes: you’ve changed your PHP version to one that’s not compatible with your old version’s serialization format, or more likely, you’ve changed your character set configurations so that string lengths in the database aren’t what PHP is expecting. Each unserialize warning represents a piece of data that couldn’t be fetched from the database and was likely discarded. These will typically be things like cover images, logos, etc.; OJS doesn’t serialize most content so it won’t be a common warning.
On CSS: Hmm, are you using URL rewriting (e.g. with mod_rewrite)?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
Yes, we use route rewriting through the .htaccess file. I believe that the previous administrators decided it this way to prevent the index.php from appearing on the routes, since having many magazines is a bit strange when going from one to the other.
About the unserialize I think it’s for both reasons:
- in the upgrade I have gone from a PHP 5.3.2 to PHP 7
- to avoid a coding error during the upgrade, perform a forced charset to UTF-8 encoding in the tables but without really changing the content, in order to have a successful update.
Now that I have all the steps and corrections to have a correct upgrade I will go back to take a dump of the production database to try to correctly repair the charset and coding of the data and thus get the upgrade of our OJS 2.4.6 in production to version 3.1.1.
Again, thanks for your help
Hi @PascualRico,
OK, sounds good. I think the rewrite rules are probably not working with the call to the CSS page; the URL should be something like…
http://testmigra.um.es/index.php/[journal path]/$$$call$$$/page/page/css?name=stylesheet
…before rewriting (with the appropriate path in place of [journal path]), and I presume your rewrite rules are to hide the index.php and the journal path.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
I have my test environment migrated and working http://revistastest.um.es, now I need to refine details and that some users confirm that everything works correctly and then I will perform the migration of the production environment.
I’m looking at the configuration but I can not find the way in which the search engine appears on the homepage, just as it happens in a specific journal, this I think is quite necessary. Could you tell me how to activate it?
Thanks for your help.
Hi @PascualRico,
That’s filed for a future addition: Add simple search form to site-wide homepage · Issue #3264 · pkp/pkp-lib · GitHub
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
Checking the update I discovered several things that have not been updated correctly:
-
The translation of variables in the Spanish language (es_ES) is not complete and I have found many references to variables not found
Ex: At the end of pages with many items it appears: ##common.pagination## because in the file lib/pkp/locale/es_ES/common.xml the line does not exist
Elementos {$start}-{$end} de {$total}
I have updated my local copy comparing with the files of the language en_US, it would be nice to know that for the next version the languages are updated correctly and thus avoid that many things erroneously show the name of the variable not found.
-
But more important is that the workflow revision forms were not updated correctly and the selection items that were predefined have been lost. From what I have seen all the forms with problems have selection buttons.
Ex: in the OJS database 2.4.6 had
(221, ‘es_ES’, ‘possibleResponses’, ‘a:5:{i:0;a:2:{s:5:"order";s:1:"1";s:7:"content";s:19:"1 (valor más bajo)";}i:1;a:2:{s:5:"order";s:1:"2";s:7:"content";s:1:"2";}i:2;a:2:{s:5:"order";s:1:"3";s:7:"content";s:1:"3";}i:3;a:2:{s:5:"order";s:1:"4";s:7:"content";s:1:"4";}i:4;a:2:{s:5:"order";s:1:"5";s:7:"content";s:19:"5 (valor más alto)";}}’, ‘object’),
(221, ‘es_ES’, ‘question’, ‘i¿Cree que resultaría interesante para los lectores de la revista?’, ‘string’)
and now in OJS 3 I have
(221, ‘es_ES’, ‘possibleResponses’, ‘a:0:{}’, ‘object’),
(221, ‘es_ES’, ‘question’, ‘¿Cree que resultaría interesante para los lectores de la revista?’, ‘string’)
This is a big problem since I have 65 journals and I would like to know if there is any way to try to force this update and recover the revision forms correctly.
Regards
Hi @PascualRico,
This is likely a result of unserialize problems, e.g. the warnings you saw above:
PHP Notice: unserialize (): Error at offset ...
When PHP can’t unserialize content, it’ll likely truncate it, resulting in the problem you describe. You’ll need to investigate why PHP is having trouble reading serialized content and resolve it. It’s likely due to encoding/connection character set changes.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
As you can see in http://revistas.um.es we already have our journal portal of the University of Murcia migrated to OJS version 3.1.1-2. I had to make some changes directly in the database but the most important thing is that important data from journals and articles have not been lost.
I have a problem in the portal I have a journal called “Arte y Politicas de Identidad” which has associated the directory ‘content/api’ but in OJS 3 there is a directory in the root called ‘api’ which creates conflict and prevents the main page of the journal from being displayed (http://revistas.um.es/api).
I initially solved the problem by changing the ‘content/api’ folder of the magazine to ‘content/apid’, as well as all references in the database, but this also makes their route different (http://revistas.um.es/apid) and therefore the external references to this journal no longer work, as well as the DOIs already assigned to articles.
The managers of the magazine inform me that due to this they are losing all the prestige gained in SJR (Scientific Journal Rankings) and that losing the link of the DOI is also very serious.
Can you think of any other way to solve this problem?
Regards
Hi @PascualRico,
That’s an unfortunate collision. We’ll be increasing our use of the API in future releases, so that URL endpoint is not going to go away.
I’d suggest building a list of links that used to go to api and adding .htaccess rules (or similar) to redirect them to their equivalents in apid instead. The complete URLs are very unlikely to have collisions.
Regards,
Alec Smecher
Public Knowledge Project Team