'Manage Article DOIs' status all over the place

Hi there,

We’ve started the process of setting up journals to register DOIs (in We have a journal with about 1200 articles that we’ve registered, and our ‘success count’ in the CrossRef admin interface lines up, but the article status on the OJS side is a mess:

75 are ‘failed’ - all the ones I’ve checked resolve & appear in CrossRef
25 are 'submitted’ - all the ones I’ve checked resolve & appear in CrossRef
701 are ‘not deposited’ - almost all of the ones I’ve checked (38 out of 40) resolve & appear in CrossRef (not sure about those last two, but I think a separate issue)
Many have the status ‘marked registered’ - All the ones I’ve checked resolve & appear in CrossRef
0 are ‘deposited’ or 'active’

So we’ve made some kind of mess, and I’m not sure how to clean it up. I can mark all as registered and move on, but I’d like to avoid this pastiche with our next journal.

Can anyone lend any guidance on where the confusion might be stemming from?

Hi @jwhyteappleby

Have you registered all your journal articles from within OJS? – OJS can only track the status of articles registered from within OJS correctly. For that we are using Crossref deposit API and search and display the status of the last batch/deposit ID. If several articles are deposited at once (having the same batch/deposit ID) and if one DOI registration fails, all the articles registered together will have status = failed (we are not able to differentiate each DOI in a batch deposit using the Crossref deposit API). Also we only look at the last batch/deposit ID, because it could be that a DOI is already registered and resolve, but after that a metadata update (a new DOI registration) was done, so we are interested only in that last deposit status. Also, I think, what we get via the deposit API is not the same what you can see in the Crossref portal, if the articles are not deposited via the deposit API :frowning:
Those with the status failed and submitted seem to be registered from within OJS. There could be several reasons, why the status is so, for example:
a) if an attempt to register them from within OJS failed, but then they were registered manually via the Crossref portal successfully (or in the opposite order)
b) if they were manually registered via the Crossref portal and there is a mismatch in the Crossref systems (portal and deposit API), which apparently does happen some times i.e. those two systems seem not to fully communicate with each other :frowning:
c) the status ‘submitted’ should actually change with the time, so if it stays like that forever it seems like a processing at Crossref sopped for a reason or it is b) above.
Those with ‘not deposited’ seem not to be registered from within OJS.
Those ‘marked registered’ are manually marked as such by someone – this is ok – this function is meant to help when articles are registered manually, not from within OJS (because OJS cannot track their status correctly and for user to know that they are already handled). Thus, if the articles are registered via the Crossref portal and not from within OJS, this function should always be used – the user cannot rely on the status retrieved via the deposit API in that case.

Does this help any further/explains anything?
We are interested in any further information that could help figure out what is happening and help us improve it…


Hi Bozana,

Thanks for the detailed response. Sorry, I should have said that yes, all deposits happened through the OJS interface. We have not done any manual registration. So the good news is, the deposit through OJS worked!

Your explanation does help me think through a few things. I hope I can state this clearly:

  • We first tried submitting the single page registration (selecting 25 on a page and hitting ‘register’) three times…which would explain the exactness of the numbers 75/25 (though not why this equals 100 rather than 75)

  • We then realized we could select whole issues and register from the ‘manage issues’ page and submitted all issues at once. While all of these appear to have been registered successfully on the CrossRef side, they all stayed as ‘not deposited’ on the OJS side. I believe my colleague went in and marked some of them as registered, which explains why some are ‘marked registered’ and some are ‘not deposited’.

So, as best I can tell:

  • Those articles that were submitted individually from ‘Manage Article DOIs’ page were read by OJS as having been submitted to CrossRef (success or fail)
  • Those articles that were submitted from ‘Manage Issue DOIs’ page were not read by OJS as having been transmitted to CrossRef (not deposited)

Another confusing piece is the fact that on said ‘Manage Issue DOIs’ page there are two issues that are marked as registered. None of the articles in these two issues have ‘success/fail’ as their status; all are marked ‘not deposited’.

There is another issue with the XML deposit that I’m talking to CrossRef about and that may deserve its own ticket here…this issue resulted in a number of ‘failed’ counts in our deposit. But a failure on the CrossRef side should then presumably lead to a failure on the OJS side - not a ‘not deposited’ status, correct?

I hope this is not too convoluted!

Thanks again,

Hi Jacqueline,

OK, yes, that explains everything:

  1. When registering by an issue, the article status does not changes and is not updated, s. ojs/CrossRefExportPlugin.inc.php at ojs-2_4_8-2 · pkp/ojs · GitHub – so to say the article status is disconnected from the issue registration in OJS. I will see with other team members if this should change, because it would mean so much more processing, so that the issue registration would not be that efficient any more. This would also mean that eventually not many issues can be selected at once, because of the server timeout possibility.
  2. “Register” changes to “Update” for an issue only if all articles from that issue have been registered. Thus, maybe some of the articles from the two example issues from the screenshot are not registered i.e. there is not the appropriate mark in the DB?

Thus, for further procedure, for further journals: maybe to either use article registration (in order to be able to track the status in OJS) or, if using the registration by issues, to marked those articles as registered manually. For those huge registrations of back issues it would make sense to register by issues and manually mark the articles as registered. The (automatic) article registration is more for continuous and current publication, when (automatically) registering new published articles.

Thanks a lot!

Okay, thank you so much for that helpful response! Since users would then need to perform the “mark as registered” action 25 articles at a time, perhaps it just makes sense for them to register them that way.

Last thing - I’m not sure I understand your last line—my assumption with automatic registration is that one doesn’t need to touch any of this, if all works as it should.

Again, I really appreciate the response!

Hi @jwhyteappleby

Yes, your assumption is correct, but with such a huge amount of articles to be registered at once, the automatic registration could eventually not work – because it could come to the server timeout i.e. the processing would stop. Thus, those big registrations should be best done semi-manual i.e. split apart or manually marked as registered … I hope we can improve all that in the future…


We’ve re-registered large numbers (thousands) of articles using automatic registration. When run from the shell or by cron, you don’t have the same limitations and timeouts as with the acron plugin.

Hi I have enabled the crossref and DOI export plugins in one of our journal sites, (QUeen’s Library is registered to deposit) but at upload stage - I do not see any articles loading in OJS,
Why might this be - what am I missing? If its easier to call please do 1 613 533 6000 x 77529

Hi @rcoughlan

What OJS version are you using?
Did you also enabled and set up the DOI public identifier plugin?
In OJS 2.4.x the DOIs are assigned so to say automatically, but in OJS 3.x you would need to explicitly assign them to each article…