We upgraded an instance of OJS from 3.1.1.2 to 3.3.0.7. For some reason now DOI on articles are resolving to the interim folder that OJS was in during the upgrade, ojs-3.3.0-7. For example:
It was in that subfolder as soon as I unzipped it, but it was moved to the correct folder location, and my base URL is set correctly in config.inc.php.
Nothing was changed with the DOI plugin and it still appears set correctly. Any ideas?
Do you have scheduled_tasks enabled in your config file and perhaps loaded that temporary folder in a browser after you performed the upgrade, before you moved it to the correct location? It’s possible the crossref deposit task ran and updated your DOIs. Can you try re-submitting your DOIs, either by exporting the XML using the plugin and uploading it to Crossref or by running the scheduled task again?
I had this happen to me once, when I was testing an upgrade on my laptop and the DOIs in that install temporarily changed to the localhost URL until I updated the DOIs on the live site again.
@jnugent Thank you for your reply. Is it one of these that is the scheduled task you are referring to?
Reassign DOIs
If you change your DOI configuration, DOIs that have already been assigned will not be affected. Once the DOI configuration is saved, use this button to clear all existing DOIs so that the new settings will take effect with existing objects.
Assign DOIs
Assign DOIs to all published journal objects that have not been assigned DOIs. This action can not be used with the individual suffix configuration. If you have modified the DOI configuration above, please save your changes before initiating this action. Assigning DOIs may take a long time, depending on the number of published objects in the journal.
Yes, but I don’t know if it’s necessary to clean out all of your DOIs since that will also reset the ones that are working. You might be able to do this in the publication_settings database table if you are (or have someone) handy.
I can find no reference in the database to the improper DOIs, but I do see this in the database for one of the articles that is incorrect:
Record not processed because submitted version:
submission_settings VALUES (2,’’,‘crossref::batchId’,’_1633893533’),(2,’’,‘crossref::failedMsg’,'Record not processed because submitted version: 1633893533 is less or equal to previously submitted version 202005202359
There’d be no stored local URL that the DOI resolves to in the database, but if you knew e.g. that the problem only affected certain issues, you could just clear those specific articles.