Error upgrading from ojs-3.3.0-20 to ojs-3.4.0-9

Describe the issue or problem

— If you see missing text in my post that is data sanitization. —

I am running upgrade from ojs-3.3.0-20 to ojs-3.4.0-9, After running upgrade command “php tools/upgrade.php upgrade” I got the following errors:

Example of error:

A row with “author_id”=“111111” and “setting_name”=“biography” found in table “author_settings” which will conflict with other rows specific to the locale key “en” after the migration. Please review this row before upgrading.

[root@machine ojs]# php tools/upgrade.php upgrade
2025-06-26 15:11:06 [pre-install]
2025-06-26 15:11:06 [load: upgrade.xml]
2025-06-26 15:11:06 [version: 3.4.0.9]
2025-06-26 15:11:06 [code: Installer Installer::checkPhpVersion]
2025-06-26 15:11:06 [code: Installer Installer::installDefaultNavigationMenus]
2025-06-26 15:11:06 [code: Installer Installer::migrateStaticPagesToNavigationMenuItems]
2025-06-26 15:11:06 [migration: PKP\migration\upgrade\v3_4_0\I10249_FixProfileImageDataLoss]
2025-06-26 15:11:06 [migration: APP\migration\upgrade\v3_4_0\PreflightCheckMigration]
2025-06-26 15:11:56 [A pre-flight check failed. The software was successfully upgraded to 3.3.9.9 but could not be upgraded further (to 3.4.0.9). Check and correct the error, then try again                      .]
2025-06-26 15:11:56 [revert migration: PKP\migration\upgrade\v3_4_0\I10249_FixProfileImageDataLoss]
2025-06-26 15:11:56 [downgrade for "PKP\migration\upgrade\v3_4_0\I10249_FixProfileImageDataLoss" unsupported: Downgrade not supported]
ERROR: Upgrade failed: DB: A row with "author_id"="90114" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en"                       after the migration. Please review this row before upgrading.
A row with "author_id"="95" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="116" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="951" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="983" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="959" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
...
...
...
A row with "author_id"="928" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="29" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="4" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.
A row with "author_id"="95" and "setting_name"="biography" found in table "author_settings" which will conflict with other rows specific to the locale key "en" after the migration. Pleas                      e review this row before upgrading.

[root@machine ojs]#

Steps I took leading up to the issue

  1. Downloaded version https://pkp.sfu.ca/ojs/download/ojs-3.4.0-9.tar.gz
  2. Replaced current version ojs-3.3.0-20 with ojs-3.4.0-9, replaced and update new config.inc.php with current config.inc.php, replace and update new public dir with current public dir
  3. ran upgrade command and found errors as above
  4. Note: I had other errors but I was able to resolve myself such as below. I resolve by moving usageEventLogs/*.log to a temp directory like empty out usageEventLogs to overcome the issue and I will try to resolve of these log files after upgrade - not sure how I will reprocess them any suggestion is appreciated:
ERROR: Upgrade failed: DB: There are one or more log files that were unable to finish processing. This happens when the scheduled task to process usage stats logs encounters a failure of some kind. These logs must be repaired and reprocessed or removed before the upgrade can continue. The logs can be found in the folders reject, processing and stage in /data/production/usageStats.

What application are you using?
It is: OJS 3.3.0-20

What have I tried:

I tried to resolve this “ERROR: Upgrade failed: DB …” by querying FROM table author_settings, WHERE field setting_name = ‘biography’ all the author_id in question taken from the error log above where (locale IS NULL OR locale = ‘’) but no result return, so I think my table and field and data in question are good. I please ask for your help of what have I missed. Here are my example queries:

SELECT author_id, setting_name, locale, setting_value
FROM author_settings
WHERE setting_name = 'biography'
AND (locale IS NULL OR locale = '')
AND author_id IN (
  914, 905, 906, 951, 983, 909 , 959, 296, 918, 926, 927,
  961, 962,
);

Screenshot for above query 1:

So I ran other sql query to find duplicates with ‘en’ locale, but no duplicated found so again I think my database is perfect. Please tell me what is it still an issue that I do not see, is it field name or literal string value convention:

SELECT author_id, COUNT(*) FROM author_settings
WHERE setting_name = 'biography'
AND locale = 'en'
GROUP BY author_id
HAVING COUNT(*) > 1;

Screenshot for above query 2:

Additional information

So I examined one record for example this is what I see, the literal string ‘en’ and ‘biography’ are there, what do you think:

Lastly when I look at the entire table, this is what I see:

Kindly thank you for any help.

Dung.

Hi @dung,

OJS 3.3.0-x used en_US for an English locale code, and 3.4.0-x and newer use en instead. So I’m curious about the en records in your 3.3.0-x database – I’m not sure where those came from. Is it possible that there was an import of XML data from a 3.4.0-x installation? Or a failed upgrade attempt that wasn’t restored from backup?

The error is occurring because the 3.3.0-x to 3.4.0-x upgrade tries to change en_US locale codes to en, but the already-existing en records are in the way.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

Thank you for your response, to answer your questions:

Is it possible that there was an import of XML data from a 3.4.0-x installation? → I do not understand this and how to confirm if there is?

Or a failed upgrade attempt that wasn’t restored from backup? → I restored database after every failed attempt before running upgrade again.

Please let me know.

Dung.

Hi @dung,

An XML import would mean using one of the plugins in Tools > Import/Export to import data into OJS from some other source.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

It’s possible and probably that other users have done that. Given that this may have happened, and now dealing with the conflicts, would you recommend that I manually change any locale values that are currently ‘en’ back to ‘en_US’ to match the correct 3.3.x format?

Sql to update: UPDATE author_settings SET locale = 'en_US' WHERE setting_name = 'biography' AND locale = 'en';

Thank you for clarifying.

Best regards,
Dung

Hi @dung,

If it runs successfully, then it’ll solve the problem – based on the screenshot above I think you’ll run into duplicates where there’s already an en_US row for the same author. You’ll have to identify those and remove whichever row isn’t useful.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

*This is to share with other people. Following the Alec’s pointer, I have successfully overcame the above upgrade issue:

  1. this query will show rows with unwanted locale ‘en’ - it should be ‘en_US’ (my case 32 rows):
SELECT * FROM author_settings
WHERE setting_name = 'biography'
AND locale = 'en';
  1. this query will show all duplicate author_id to use in the next delete duplicate query:
SELECT author_id
FROM author_settings
WHERE setting_name = 'biography'
AND (locale = 'en' OR locale = 'en_US')
GROUP BY author_id
HAVING COUNT(*) > 1;
  1. this query will delete unwanted duplicate rows locale = ‘en’:
DELETE FROM author_settings
WHERE setting_name = 'biography'
AND locale = 'en'
AND author_id IN (
  -- Replace with author_ids you found duplicated
  20024, 20025, ...
);
  1. this query is to confirm your deletion. It should return 0 rows.
SELECT * FROM author_settings
WHERE setting_name = 'biography'
AND locale = 'en';

At this point you have successfully overcame this specific issue. But the upgrade ran into different issue for me. I will continue resolve it until there is no issue.

D.

1 Like

Hello @asmecher ,

I now got this error message, after another fresh upgrade run:

ERROR: Upgrade failed: DB: Contact name or email is missing for context(s) with path(s) [JournalCA3,UCP]. Please set those before upgrading.

So what I did was trying to add a valid contact name, and A valid contact email. To do so I need to find missing ‘contactName’, ‘contactEmail’ so that I can add valid ones, but the below query return 0 records.

 SELECT j.journal_id, j.path, js.setting_name, js.setting_value
FROM journals j
LEFT JOIN journal_settings js
  ON j.journal_id = js.journal_id
WHERE j.path IN ('JournalCA3', 'UCP')
  AND js.setting_name IN ('contactName', 'contactEmail');

Do you have any suggestion for me in order to overcome this ERROR in screenshot above.

Thank you so much for pointing me.

Dung.

Hi @dung,

That’s the problem exactly – that query doesn’t return any rows. You’ll have to insert them. (The friendliest way to do this is probably to go into your 3.3.0-x installation and edit the journal settings there, then make a database backup and try to upgrade with that.)

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks @asmecher

So I pointed the 3.3.0-x installation to the db and used the interface to add (‘contactName’, ‘contactEmail’) as in screenshot below:

This resolved the issue. Run the upgrade command again, then I ran into another Error

ERROR: Upgrade failed: DB: Some DOIs have been registered with multiple registration agencies. Resolve duplicates before continuing by running `php tools/resolveAgencyDuplicates.php`.

So I ran command: php tools/resolveAgencyDuplicates.php

Then I got error:

php tools/resolveAgencyDuplicates.php
Script to resolve DOI registration agency duplication pre-3.4.
NB: If a conflict exists for a submission, the corresponding publication objects (galleys, etc.) will also be cleaned up.

Usage:
tools/resolveAgencyDuplicates.php resolve [agency_name] --force : Remove conflicting DOI registration info, keeping agency_name.
tools/resolveAgencyDuplicates.php test : Returns list of conflicting items

Options:
agency_name      One of: crossref, datacite, medra.
--force          Force resolve operation. Will not delete data without it.

Run this command first php tools/resolveAgencyDuplicates.php test to see which DOIs are duplicated such as IDs with duplicate DOI registration metadata. This will list all conflicting DOIs, submissions, or galleys that have multiple agencies?

Example:

 php tools/resolveAgencyDuplicates.php test
IDs with duplicate DOI registration metadata:
Submissions: [30322,30323,30324,30325 ... ,55658,55660,56818]
Issues: []

Go to next comment.

Hello @asmecher ,

I searched AI and found answer below, is this correct, can you help clarifying:

Thank you!
D.

Hi Alec,

This is where I am standing just in case this extra info helps:

The next logical command to run is:

php tools/resolveAgencyDuplicates.php resolve Crossref --force

But my OJS admins said in our system we do have a mix of Datacite DOIs and Crossref DOIs.

And that if I ran the above command, would the command get rid of all Datacite DOIs in the system? If so, that wouldn’t be a good thing as we’d have a bunch of missing DOIs for articles and issues.

Can we still reserve both agencies Crossref and Datacite in version 3.4.x @asmecher ?

Thanks again.
D.

Hi @dung,

It would not remove all Datacite DOIs, just ones where it conflicts with the Crossref ones. As a first step I would recommend running the following just to see which entries it says have duplicates. That might give you a better idea of what’s going on.

php tools/resolveAgencyDuplicates.php test

Regards,

Erik
PKP Team

Thank you again for your help so far.

We previously registered DOIs through DataCite, but switched to CrossRef a couple of years ago. At that time, we disabled the DataCite configuration and enabled the CrossRef configuration for our journals.

Dung has extracted a list of 4,054 entries identified as duplicates. I’ve reviewed several of them and noticed that the DOIs were originally registered with DataCite. In the DataCite Export/Registration Plugin, these records appear as “Registered,” while in the CrossRef XML Export Plugin, the same records appear as “Marked active.”

Given that our current configuration uses CrossRef, we’re concerned that the legacy DOIs registered with DataCite may become misconfigured or cause issues.

Would you be able to advise on the best way to proceed?

Best wishes,
Gabriela

Hello @ewhanson

@gabriela1 is our Journal admin has given the details. In addition and to answer your question here is a snippet after running the test command:

Start:

End:

As Gabriela explained, and that my understand is there are conflicts in our DOIs being in both agencies unfortunately, and unlike version 3.3.x we could have multiple agencies at once, in version 3.4.x there is only one agency allowed. Can you kindly provide me best course of action to take to overcome this upgrade Error.

Best,
Dung.

Hey @gabriela1 and @dung, thanks for providing the additional details. A few more questions before making a concrete recommendation:

  1. For the DOIs that had previously been registered with Datacite, have they been transferred over to Crossref or are they still registered and resolved via Datacite?
  2. Do you exclusively use Crossref for registering DOIs now?

Thanks!

Regards,

Erik
PKP Team

Hello,

  1. For the DOIs that had previously been registered with Datacite, have they been transferred over to Crossref or are they still registered and resolved via Datacite?
    • They are still registered and resolved via Datacite
  2. Do you exclusively use Crossref for registering DOIs now?
    • Yes

Thank you,
Gabriela

Hello @ewhanson

In addition, here is what my colleague found: the DOIs were originally registered with DataCite. In the DataCite Export/Registration Plugin, these records appear as “Registered,” while in the CrossRef XML Export Plugin, the same records appear as “Marked active.”

Does this help understanding our issue.

Thank you!
D.

Hi @dung and @gabriela1, yes that helps a lot.

One final question: have any of the DOIs been double registered, i.e.registered with both Crossref and Datacite?

Regards,

Erik
PKP Team

Hi @ewhanson

Our OJS admin does not have a definite answer for this question. 1) Would you be able to present solution to both scenarios 2) And do you have a backup solution just in case we have to reverse?

So much appreciated your guidance

Dung