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

Software Support
,
1

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…

Technical background is required to understand and perform those actions.

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.

11. DB Error: Data too long for column ‘contents’ at row 1…

This error is similar to error 10 but for table article and field “comments_to_ed”.
I happens when (for instance) authors decide to send the article to the editor doing a cut&paste of the word content into the “editor’s comment” field.

Solution was proposed by Alec here:

To find the articles that are breaking your upgrade, you need to run this query:

SELECT article_id, `comments_to_ed`, length(`comments_to_ed`) as comments_length 
FROM `articles` ORDER BY `comments_length` DESC

Here you will find one or more rows with a lenght bigger than 64K, so you can run an update query or go your ojs2 and delete or modify the content of this field to make it shorter…

Notice you only can delete the content of this field, not the full row. Otherwise you could generate additional inconsistencies.

12. There are no readable files in this directory tree…

It happens when you upgrade from 2.x to 3.x and you have articles without an assigned section.
How is this even possible? Well… don’t underestimate what users can do with quicksubmit and other import tools.

Full error is:

[code: Installer Installer::moveReviewerFiles]
<h1>There are no readable files in this directory tree. Are safe mode or open_basedir active?</h1>ojs2: There are no readable files in this directory tree. Are safe mode or open_basedir active?

You can find some posts talking about this issue in the forum:

Till solution is posted here: Upgrade from OJS 2.4.7 to 3.0.1 fails - #18 by asmecher

Easiest way to find the orphan articles, is running this query:

SELECT * FROM articles WHERE section_id IS NULL;

Then, you can update the articles to assign a section touching your DB (as Alec explains in detail in former post) or go to your ojs and change them manually.

13. WARNING: The NavigationMenu…” (by @murilodbva)

I managed to resolve that warnings by removing orphan navigation_menus.

If necessary, it can works for you too:

CREATE TEMPORARY TABLE IF NOT EXISTS navigation_menus_2_delete AS (
    SELECT s.navigation_menu_id
    FROM navigation_menus s
        LEFT JOIN rt_contexts j ON (s.context_id = j.context_id)
    WHERE j.context_id IS NULL
);

DELETE FROM navigation_menu_item_assignments WHERE navigation_menu_id IN (
    SELECT navigation_menu_id
    FROM navigation_menus_2_delete
);

DELETE FROM navigation_menus WHERE navigation_menu_id IN (
    SELECT navigation_menu_id
    FROM navigation_menus_2_delete
);

DROP TABLE navigation_menus_2_delete;
9 Likes
3

@marc

it really is very helpful !!

Thanks!

1 Like
4

Today I realize I started a similar list back in 2019, when I helped some fellows with their migration… :sweat_smile:

(todo: move issues to this list and close the former one) :thinking:

6

@rahulp411 this is a list of issues with known solutions.

If you are facing an error that is not in the list or the solution proposed here is not working, open a new thread and we can talk there. Once we found the solution, post here your new solution.

If you open a new post, please remember you need to be specific explaining:

  • Your installation (os, php, mysql and OJS versions).
  • Your exact error (capture the logs in the moment it happens).

Cheers,
m.

1 Like
11

About “03. WARNING: The NavigationMenu…”,

I managed to resolve that warnings by removing orphan navigation_menus.
If necessary, it can works for you too:

CREATE TEMPORARY TABLE IF NOT EXISTS navigation_menus_2_delete AS (
    SELECT s.navigation_menu_id
    FROM navigation_menus s
        LEFT JOIN rt_contexts j ON (s.context_id = j.context_id)
    WHERE j.context_id IS NULL
);

DELETE FROM navigation_menu_item_assignments WHERE navigation_menu_id IN (
    SELECT navigation_menu_id
    FROM navigation_menus_2_delete
);

DELETE FROM navigation_menus WHERE navigation_menu_id IN (
    SELECT navigation_menu_id
    FROM navigation_menus_2_delete
);

DROP TABLE navigation_menus_2_delete;
1 Like
12

Thanks for your contribution @murilodbva.
Your tip is now added to the wiki initial post.
Feel free to modify if is not as you want.

Take care,
m.

1 Like
13

Nice, Thanks for the Information! It helps to everyone.

2 Likes