automatic registration with CrossRef failed on an OJS 2.4.8.-0 installation. We are using cron jobs, acron is disabled. The scheduled task started but did not finish (scheduled taks log in the files folder).
There are still articles in the registration queue that had failed - assumingly due to special characters in the DOI.
My current assumption is that the plugin tries to register the failed articles each time the automatic registration is activated. And that it quits the job as soon as it encounters the first article that leads to a fail. And that results in no registration at all. Registering via the register button works fine.
Can you confirm that this is the way the automatic registration works?
Note that the Crossref plugin was significantly changed/improved since OJS 2.4.8-1, that came shortly after the 2.4.8.0 release.
In general: It is best to use the OJS current stable GitHub branch or at least most recent OJS release as soon as possible – the changes, bug fixes and improvements happen quickly…
Else, see also this post regarding the status change and used Crossref deposit API: [OJS 3.0.2] CrossRef XML Export Plugin: Status not refreshed properly.
I.e. Could you double check the status of those DOIs using that API URL from that post i.e. if the status is “submitted” also there. (Sometimes there is a problem with that Crossref API – it is not seen as ‘productive’ but we also do not have any other way/solution for now). In that case, could you try to contact the Crossref support and ask why the deposits are not processed. Else, let me know what do you see from that URL response.
And finally, if you consider upgrading to the OJS 2.4.x version then please not to the 2.4.8-1 but to the most recent one…
After reading it, I retried to register the articles with the register button and this time, it worked. So maybe it was just a problem with the connection or with CrossRef last week.
The status was also updated for most of the articles, althought it occured very slowly (taking several hours for some articles) and there are about 40 left in the submitted state. It switched to “found”, not to “completed”.
The automatic registration still does not work. I will test it again when new publications need to be registered.
the crossref settings in table article_settings of one of our installations are (still) not consistent, so I consider a cleaning up.
Are these settings:
necessary for the plugin? If I would download/upload the xml-files to CrossRef, I wouldn’t have this data in OJS anyway, so I guess they cannot be necessary?
If I had a more recent OJS version with a button for status check, would all crossref settings (depositStatus, depositStatusUrl, registeredDoi) be updated for all articles when applying the status check?
necessary for the plugin? If I would download/upload the xml-files to CrossRef, I wouldn’t have this data in OJS anyway, so I guess they cannot be necessary?
Those settings: depositStatusUrl and regisgteredDoi are necessary for some plugin functions: For example, the depositStatusUrl is used to provide the link for the user where he/she can see the deposit failure messages. The registeredDoi is used to figure out what objects (e.g. articles) have not been registered yet, I think.
If the manual deposit/registration is used, then the settings depositStatusUrl is not important, but the registeredDoi could still be used – For example, if the user marks the object as registered, this setting would be used/set.
If I had a more recent OJS version with a button for status check, would all crossref settings (depositStatus, depositStatusUrl, registeredDoi) be updated for all articles when applying the status check?
Yes, the plugin would always take the most recent deposit status (because it could be several deposit/registration attempts) and save that URL. The registeredDoi would be used as said above – to note that the DOI/object has been registered.