Unable to Edit Mistyped DOI in OJS 3.4

I’m encountering an issue with editing a DOI in OJS 3.4. Here’s the scenario:

  • Incorrectly Entered DOI: The article was accidentally assigned a DOI with a typo: 10.XXXXX/.XYZ.2024.06.005
  • Desired Correction: The correct DOI should be 10.XXXXX/Q.XZY.2024.06.005 (adding “Q” before the dot).

However, OJS 3.4 seems to be preventing the correction:

  • Attempted Edits:
    • Changing the DOI to the desired format results in it reverting back to the incorrect version.
    • Only possible edit to leave the whole DOI blank, such correction is accepted by the system.
    • Entering the desired DOI triggers an error message: “Some DOI(s) could not be updated.”

Is there a way to edit a mistyped DOI in OJS 3.4?
Are there any workarounds to achieve the desired correction?

@asmecher any thoughts?

Hi @Garant,

It should be possible to edit it, so this definitely sounds like a bug. Thanks for sharing the error you did see. Is there any further detailed information in the network tab in the developer tools?

I’m also wondering if this happens with any DOI you’re attempting to edit or only with this specific one.


PKP Team

Hi @ewhanson ,
indeed, there is an error in the console.
There were only a few times when I had to edit DOIs, so as far as I remember some of them were edited without problems some of them were also reverting back to the root prefix… But I don’t remember clearly…

Thanks so much @Garant. Could you let me know what’s in the “Response” tab?


PKP Team

Sure, here is it:

But the situation is strange for me…
I check the mistyped DOI by opening the URL:
it points to the article, that’s OK, how should be.

But if I open the “right” DOI, to which I want to change the mistyped DOI by entering this URL
I also get forwarded to the same article…

Thanks @Garant, that’s helpful. I’m not sure how this would have happened, but the “right” DOI is already in use somewhere in your installation, which is why you can’t add it to correct the mistyped one.

To dig into this, you may need to check in the database manually, unless you can easily see on the same item that another publication/galley is using the “right” DOI.

To see where this is happening, you can run the following SQL query (with your actual, “right” DOI instead of the placeholder prefix:

select * from dois where doi = '10.XXXXX/Q.XYZ.2024.06.005'

With any luck, this should return at least one DOI. You can then try and find where it’s already in use. It will be a doi_id in one of these tables: publications, publication_galleys, or issues. If it was accidentally added to something you didn’t mean, it will most likely be okay to delete that row in the database, edit the mistyped DOI, and resubmit.

Of course, before you make any changes to the database, make sure you have made appropriate backups and are able to restore the database if anything goes wrong.

Hope that helps. If you have any other questions about this, feel free to ask!


PKP Team

1 Like

Thank you!
I will ask the IT administrator to run the SQL query and check it

Hm, strange, administrator ran this query:

select * from dois where doi = '10.13165/j.icj.2024.06.005'

and got this results:

mysql> select * from dois where doi = '10.13165/j.icj.2024.06.005';

ERROR 1146 (42S02): Table 'ojs.dois' doesn't exist



is right DOI to which I want to change the mistyped 10.13165/.icj.2024.06.005

@ewhanson , any thoughts, why it’s producing this error?

The table dois should be there, did he choose the database (“use” statement) before executing the select query.

Has the wrong doi and the associated metadata already been registered with Crossref?
Then registering with the correct DOI should lead to a conflict there, which you have to resolve with Crossref.

1 Like

And the SQL results are:

| doi_id | context_id | doi | status |


| 1500 | 14 | 10.13165/j.icj.2024.06.005 | 1 |

As I know at the beginning the wrong DOI was registered, then it was changed to correct. So, it’s a root of a problem?

The table dois should be there, did he choose the database (“use” statement) before executing the select query.

Will recheck it, thank you!