We upgraded an instance of OJS from 220.127.116.11 to 18.104.22.168. 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:
now gives us:
The requested URL /ojs-3.3.0-7/index.php/RNO/article/view/629 was not found on this server.
So it’s going to:
When it should just go to:
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.
It’s also worth mentioning that I looked through your archives and your old DOIs are still resolving fine, e.g. these articles:
So I suspect this is what happened. These may have also updated but are perhaps updating back already.
@jnugent Thank you for your reply. Is it one of these that is the scheduled task you are referring to?
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 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.
Yes I was hesitant to reassign all DOIs in the fear of breaking prior links, but I don’t see this anywhere in the database to manipulate manually.
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
Unsure if this is relevant…
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.
That other error, regarding a submitted version being less than equal, etc, was described quite well by Mike here: Old DOIs become unactive - #2 by AhemNason