Common errors when upgrading to OJS 3.2.x from OJS 2.x

This post is a compilation of errors/warnings I found in the upgrade of the 50 independent OJS in our service.

With OJS 3.3 released and only 1/3 of journals in OJS2.x most of you will find this post useless, but I feel like I need to share those notes, just in case it could be useful for somebody else…

This list could/would be extended and/or modified: Feel free to comment if you think relevant errors are missed.

IMPORTANT:
If you use any of the solutions posted here, be careful and be sure you have a backup of your DB and files. This is a must before any upgrade process. If the jump between versions is big, is highly recommended do the upgrade from the command-line. You will get better feedback.

01. PHP Notice: Only variables should be assigned by reference…

PHP Notice: Only variables should be assigned by reference in /var/www/html/lib/pkp/classes/db/DBDataXMLParser.inc.php on line 122

This is not an error, it’s only a “notice” is generated by changes between php versions and could be safely ignored.

02. PHP Warning: Declaration of SubmissionLanguageEntryDAO…

[code: Installer Installer::migrateArticleMetadata]
PHP Warning: Declaration of SubmissionLanguageEntryDAO::getByControlledVocabId($controlledVocabId, $rangeInfo = NULL) should be compatible with ControlledVocabEntryDAO::getByControlledVocabId($controlledVocabId

This is not an error, it’s a “warning” that could be safely ignored.

03. WARNING: The NavigationMenu…

[code: Installer Installer::installDefaultNavigationMenus]
WARNING: The NavigationMenu (ContextId: 1, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 1, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 0, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.

This is not an error, it’s a “warning” that could be safely ignored.

More info: OJS 3.2.1-1 upgrade warnings - #4 by asmecher

04. ERROR: Reviewer files with ID…

[code: Installer Installer::moveReviewerFiles]
ERROR: Reviewer files with ID 2696 from review assignment 448 could not be found in the database table submission_files
ERROR: Reviewer files with ID 3364 from review assignment 638 could not be found in the database table submission_files

Ok. This is a real error, but upgrade process is resilient enough to overcome it.

OJS is telling you that is not able to find files that were attached during a reviewing process.
In very rare situations a file can be included to the DB but not stored to the disk.
If it happens, there is no solution… but asking the journal to find the file and recover it or live with the missing file.

To discover what articles are hit by this error you can run this query in your 2.x database (pre-upgrade):

SELECT review_id, submission_id, reviewer_id, recommendation, date_assigned, date_completed, last_modified, reviewer_file_id, round, step, review_form_id
FROM review_assignments
WHERE reviewer_file_id in (2696,3364)

05. ERROR: Upgrade failed: DB: Duplicate entry…

[data: dbscripts/xml/upgrade/3.0.0_update.xml] ERROR: Upgrade failed: DB: Duplicate entry ‘373-48-452-1’ for key 'review_round_files_pkey’

This is an error that needs to be actively addressed.
OJS is telling us that some rows in the review_rounds table are inconsistent and you need to help it cleaning the orphan rounds to avoid duplicates.

To check the rows that collide:

  SELECT * FROM review_rounds WHERE review_round_id NOT IN (SELECT MIN(review_round_id);

If you like to remove the duplicates (use with caution):

  CREATE TABLE review_rounds_old SELECT * FROM review_rounds;
  DELETE FROM review_rounds WHERE review_round_id NOT IN (SELECT MIN(review_round_id) FROM review_rounds_old GROUP BY submission_id, round);
  DROP TABLE review_rounds_old;

More info:

06. PHP Warning: Cannot assign an empty string to a string offset…

PHP Warning: Cannot assign an empty string to a string offset in /var/www/html/lib/pkp/classes/core/DataObject.inc.php on line 133

This is not an error, it’s a “warning” that could be safely ignored.

07. License disappears after upgrade to 3.x

If after upgrade to 3.x you notice the license of each article is missing, this is caused by a change of criteria in the naming of the variable “licenseUrl”, that sometimes could be “licenseURL”. This simple query is is enough to fix this.

UPDATE journal_settings SET setting_name='licenseUrl' WHERE setting_name='licenseURL';
UPDATE publication_settings SET setting_name='licenseUrl' WHERE setting_name='licenseURL';

More info:

08. PHP Fatal error: Uncaught Error: Call to a member function getFileId() on null …

Different scenarios can tigger this error:

First case is quite obvious but second probably needs more explanation.
It happens in 3.1.2 (or greater) when a supplementary file is missing due former migration errors, virus attacks, out of services, etc.

The error looks like this:

[code: Installer Installer::provideSupplementaryFilesForReview]
PHP Fatal error:  Uncaught Error: Call to a member function getFileId() on null in /var/www/html/lib/pkp/classes/file/SubmissionFileManager.inc.php:184
Stack trace:
#0 /var/www/html/classes/install/Upgrade.inc.php(1477): SubmissionFileManager->copyFileToFileStage('504', 1, 4, NULL, true)
...
thrown in /var/www/html/lib/pkp/classes/file/SubmissionFileManager.inc.php on line 184

This won’t be the only info in your upgrade log… you will probably get some warnings before this error telling you that some files are missing:

WARNING: Unable to find a match for "280-504-1-SP.doc" in "/var/www/files/journals/1//articles/280/". Skipping this file.

At copyFileToFileStage('504'...)" the Fatal Error is yelling that the missed file_id is 504 so you need to check your DB to find the real filename in your original 2.x DB at submission_files table with:

SELECT * FROM `submission_files`
WHERE `file_id` = '504'

Knowing the filename (ie: 280-504-1-SP.doc) and the article id (280) you can go to your files folder and create an empty file in your supplementary files folder as follows:

$ touch /files/journals/1/articles/280/supp/280-504-1-SP.doc

Empty files will be easy to find, but as an alternative solution you can also create a file with “This file was missing when the journal was delivered to this service” or “Missing file due ransomware attack on dd/mm/YY” or whatever message you find useful for your final users.

The file will be still missing (if you don’t have a backup, there is no solution for this), but after this, you will be able to run the upgrade.

09. OJS3 is fine with English but is sending blank mails (or signed but empty emails) on my local language.

Even you can find other situations where you can get empty/blank mails, most common scenarios are:

  • New email templates are not loaded
  • New languages are not loaded.

As always, make a backup of your OJS and “reset” both set of translations at:

After this, you would like to clean your cache (both: server and client side).
TIP: “Default translation” is usually a good idea.

10. ERROR: Upgrade failed: DB: Data too long for column ‘url_path’…

This error jumps when you upgrade from 2.x or 3.1 to 3.2 and is shown as:

[data: dbscripts/xml/upgrade/3.2.0_url_path.xml]
ERROR: Upgrade failed: DB: Data too long for column 'url_path' at row 13

Full issue is explained here by Nate:

In short, this happens because “public id” length is longer than 64 chars, so you have to find the article that is generating the error and fix it before the ugrade.

The easiest way to find the article is checking your pre_3.2 database. Those are the queries for 3.1.*:

SELECT submission_id FROM submission_settings WHERE setting_name="pub-id::publisher-id" AND LENGTH(setting_value) > 64;
SELECT galley_id FROM submission_galley_settings WHERE setting_name="pub-id::publisher-id" AND LENGTH(setting_value) > 64;
SELECT issue_id FROM issue_settings WHERE setting_name="pub-id::publisher-id" AND LENGTH(setting_value) > 64;
SELECT galley_id FROM issue_galley_settings WHERE setting_name="pub-id::publisher-id" AND LENGTH(setting_value) > 64;

Once you find the long “public id”, visit your original OJS, replace it with a shorter one (renew your DOIs if any) and run a new migration.

5 Likes

@marc

it really is very helpful !!

Thanks!

1 Like