Manual CrossRef DOI assignment (OJS 3.4.0.5)

Describe the issue or problem

Hi, In OJS 3.4.0.5, I tested manual DOI assignment (for articles that already had a DOI) and automatic DOI assignment (for articles that did not yet have a DOI). Both worked. I then wanted to revert to manual DOI assignment in order to finish processing articles that had already been published outside OJS with a DOI, but since then it hasn’t worked (despite various tests and plugin settings).

Does the setting in the screenshots below seem correct to you?

For information, the DOI prefix of the article is already prefilled in OJS but when I want to add the suffix here is the error message that appears: “Some DOI(s) could not be updated”. Paradoxically, if I delete the prefilled prefix and leave the DOI field empty, I get a “green” message telling me that the DOI has been updated…

Steps I took leading up to the issue
For example:

  1. Go to 'DOI"
  2. Click on the arrow to unfold the DOI rectangle => DOI prefix is already prefilled
  3. Click on 'Edit" to add the suffix
  4. See error : “Some DOI(s) could not be updated”.

What application are you using?
OJS version : 3.4.0.5
Plugin : Crossref Manager Plugin

Additional information



Hey @AhemNason,

Could you weigh in on this one?

-Roger
PKP Team

In addition: the automatic assignment of DOIs still works very well. It’s really the manual assignment that’s the problem at the moment (in the configuration shown above). .

Hey there @pauplin,

One of the issues with 3.4 is that most of our hosted clients are on the LTS 3.3.x version and I haven’t had to troubleshoot many issues with the 3.4 one. Weird quirks in behaviour like what you’re reporting are always the hardest to recreate.

My first hunch is that maybe you need to clear the template cache under the admin menu. And the data cache while you’re at it. I’d start there, but it’s also a little like asking you if you’ve tried rebooting.

I think what makes the most sense is to start there and let us know if it helps at all. I know I’ve seen some weird behaviour with fields in the plugin seemingly not remembering or saving data and I had a similar issue come to me about a month ago. I’m going to tag @ewhanson, since he knows the brains of the plugin better than I do. He’s currently travelling so it might take him a bit to reply, but if he can recreate this and we can see some error logs, that might help.

In the meantime, please try that data and template cache wipe and then what would also be helpful is if you can prompt that error you reported (“Some DOIs could not be updated”) and check the logs to see if you get anything more specific. It might help give us an idea where the issue lies.

Best,
Mike

Hi Mike,

Thanks for your help. We have cleared the requested caches but the manual DOI assignment does not work.

I don’t know if this can give you a clue: initially, when I tested this feature successfully, I had to 1) delete the prefix 2) click “Edit” again 3) paste the DOI.
If I added the suffix directly to the prefix, it did not work.

But this “trick” does not work either.

Best regards

Dear all,

Do you have any clue to fix the issue mentioned in the first post ?
Best regards

Dear @ewhanson and @ahemnason, Do you have any clue to fix the issue mentioned in the first post ? Best regards

Hey @pauplin

This helps a bit, but if you have access to your installation’s error logs, would it be possible for you to run through these steps again and then share those logs with us?

I’ll see if I can repeat this on a test instance.

Best,
Mike

Hi Mike,
Apologies for the late reply. The colleague who has access to the logs was away.
In which directory are the logs you need?
Best

Hi @AhemNason
Could you please tell me where I can find the error logs? My colleague who has administrator mode access doesn’t know where to look. Thanks in advance !

Sorry about all the delays here @pauplin. It’s been a wildly busy month. Uhh, @ewhanson where are logs kept for errors? I always ask other people to get those for me :slight_smile:

Hi all,

For information on where to find the PHP error log, see this post:

Regards,
Alec Smecher
Public Knowledge Project Team

Dear @asmecher and @AhemNason,

Thank you very much for the tutorial and I am sorry I am a bit late getting back to you. We don’t get any error logs when we try to register DOIs manually…

A closer look at the DOIs shows :

  • DOIs that could be registered manually via OJS have no ‘:’ (ex : 10.57890/VIEMILIEU/2021.71-004)
  • DOIs that could not be registered manually via OJS have a ‘:’ in the DOI (ex : 10.57890/VIEMILIEU/2024.74-1/2:1-44)

This seems to us to be the element blocking registration.
I have contacted CrossRef to confirm whether this is the problem. I will keep you posted !

Best regards,

1 Like

Hello! if you check the Crossref construction guides, a colon is not on the list of accepted characters… I’m embarrassed I didn’t catch this sooner.

https://www.crossref.org/documentation/member-setup/constructing-your-dois/

Best,
Mike

Hi @AhemNason
Thanks a lot !
CrossRef replied :

Your DOI suffix can be any alphanumeric string, using the approved characters “a-z”, “A-Z”, “0-9” and “-._;()/”.

If you OJS will allow you to export the XML out of OJS with the colon, I can get the DOI(s) with the colons registered for you for an existing DOI that is part of the migration/re-registration between DataCite and Crossref. We have an internal username that I can use to do this, but I would need Crossref formatted XML in order to do that.

I am not able to export the XML out of OJS because it has not yet a DOI and I cannot register the DOI with colon. So I am going to manually create an XML file to send to CrossRef, and they’ll be able to register these old DOIs with the colon. But I’m not sure I will then be able to inject them into OJS (we’re taking the process a bit backwards from the normal OJS circuit)…

So we will do the test with one DOI for now, and see if it works before processing all these DOIs… I’ll keep you posted. If you have any comments or suggestions, don’t hesitate!

Best regards

Dear @AhemNason

CrossRef has registered a DOI with a colon with its internal account. But as I expected, it didn’t change anything on OJS, which rejects the DOI update despite the prior registration with CrossRef.
By any chance, can you do something about this on your end?

My other solutions are :

  1. manually register the Data Cite DOIs with CrossRef (21 DOIs in total) and add them a bit messily on the article page in OJS (for example in the abstract).
  2. register new and different DOIs via OJS (with the option to randomly generate DOIs): the DOIs are no longer the same as those mentioned in the print version and cited for 1, 2, 3, 4 years… Not great in terms of editorial practice. :confused:

Best regards,

PS : I have tried to past in OJS this three DOIs forms in succession :
• 10.57890/VIEMILIEU/2024.74-1/2%3A1-44 (%3A as for an URL)
• 10.57890/VIEMILIEU/2024.74-1/2& colon ;1-44 (& colon ; as for HTML*)
• 10.57890/VIEMILIEU/2024.74-1/2:1-44 (: for a standard form)

*I’ve deliberately added spaces otherwise the characters will disappear when this message is published.

PS’ : DOIS forms with special characters…according to this documentation : https://www-crossref-org.turing.library.northwestern.edu/documentation/member-setup/constructing-your-dois/suffixes-containing-special-characters/

Dear @AhemNason,

Do you have a solution for adding DOI with colon in OJS (not to register them, as they will be registrered directly by CrossRef) but to display them on our OJS journal website. As the colon are no longer used by crossref (in the current workflow), OJS rejects them.

Best regards