OJS 3: No DOIs generated

I have activated the DOI plugin on an OJS 3.0.1 installation, but no DOIs are generated, and there are no error messages. The first few times I tried to set things up in the CrossRef XML export plugin I got an error message that said “plugin requirements not met” (or something similar), without explanation or errors in the logs. Eventually it disappeared. Perhaps there are simply some caching issues here, either way it is confusing.

No DOI numbers appear in the article descriptions, and also in the CrossRef XML export there are no articles with assigned DOIs in the list. Are there additional steps that I have missed? The same CrossRef credentials and DOI prefix are used by several other journals (running OJS 2.4.8 or older) without problems.


1 Like

Hi @simonmitternacht

In OJS 3.x the editors have to explicitly assign the DOIs. For articles this is done in the metadata modal > public identifiers tab. There you should see a DOI preview and a button to assign it to the article. Have you already done that? Once assigned the DOIs are visible on the article page and that article should also be listed in the Crossref plugin.


Ok, so there’s no batch process? This journal hasn’t had DOIs before, so we would have to go through 1-200 articles manually.

1 Like

I would be interested in a batch process as well, because our journals have just started to use DOIs and some of them would like to have DOIs for older articles as well.

Hmmm… I’ll see with the others in the team how to best provide it…


Hi @bozana

Concerning the UI I think that something similar what you have in the Crossref plugin would be good enough: basically a grid where you could list the articles and the DOI would be visible in the listing, if one existed for a article. There would be checkboxes in front of the titles and a button for creating a DOI.

Using it would of course mean that you would have to provide the settings in the DOI plugin.

We are on OJS 3.0.1 and have the same problem with migrating a journal. It’s 100 articles and a batch process would be helpful. I currently think about the following workaround:

We will import the articles using the native XML-plugin and you can suppply DOIs in
<id type="doi" advice="update">10.1234/abcdef</id>
We could mass generate the DOIs previously following the standard DOI scheme of OJS, import them and then register them later. The only drawback is, that the OJS article-DOI includes the internal OJS-ID at the end. So you have to know the next available OJS-ID before importing so that your starting point of the running number at the end of the DOI is correct.

1 Like

Hi all,

We will not implement a big solution for now, because of other priorities, but I am planing to add a button (maybe in the DOI plugin settings) that would assign DOIs to all journal articles, that do not have one already assigned… s. Add "Assign DOIs to all journal articles" button in the DOI plugin settings · Issue #2342 · pkp/pkp-lib · GitHub



I would support and vote for this with both hands, since we have lots of journals with archives, which may number in the hundreds :head_bandage:

Hi @florianruckelshausen,
Thank you for sharing this.

We are going to have exactly the same case here. So would you please give a kind of a brief steps-by-step manual.

Have you managed to update the URLs binded to DOIs when you imported your archive along with DOIs? How do we know the next OJS-ID available and what we should do with this knowledge then? :slight_smile:

Hi all, just a note: the function (s. Add "Assign DOIs to all journal articles" button in the DOI plugin settings · Issue #2342 · pkp/pkp-lib · GitHub) is coming pretty soon – I just have to change a few things after the code review – so you might want to wait for that…

1 Like

Hi @bozana,

Would you please tell what might be the ‘best practice’ in case of using the XML-import and archives with DOIs?

Hi @Ph_We,

The XML import is good for already existing DOIs e.g. if somebody wants to migrate back issues/articles that already have DOIs.
In the case that the DOIs are imported with XML, they will probably not match the default suffix patterns, because the new IDs are not known (as florianruckelshausen said), but… this also maybe does not have to be so – the DOIs can be anything, they just have to be unique within a DOI prefix.
If one imports the issues/articles that do not have DOIs and cares about how the DOIs look like i.e. that they match the default suffix pattern, and wants all (or almost all) published articles to have a DOI, it would be better to first import the articles and then user that new “Assign DOIs” function after that.


1 Like

@bozana, So we can safely use XML-import to import all the articles with existing DOIs, just keeping in mind that the suffix pattern for all the new articles will be changed in OJS.
I mean, it is not going to be an insurmountable problem for our journal managers, right?

Another question is whether they will be able to refresh URLs for those DOIs already imported (so DOIs would redirect to the new article pages in OJS)?


The only thing you will have to watch very carefully is, that the old DOIs, that you would like to import, do not clash with any existing or futer DOIs in the new system – the suffix pattern has to be very carefully chosen, so that every DOI is unique. For example: if you have an article with the ID = 1 in the old system but also another article with the ID = 1 in the new system, and if you have lets say the default suffix pattern (i.e. %j.v%vi%i.%a) for both, where all the values are the same for both article, it will lead to the same DOI for different articles which is not correct/possible.

Yes, the DOIs can then be exported/registered from within OJS again. If it is an existing DOI, Crossref will just update the metadata (e.g. URL).

1 Like


The journal we are trying to move to OJS uses the following DOIs:


I do not think there may be a clash between these and the new ones, but what would be the best way for them to proceed?
Will they be able to set up the DOI pattern in OJS exactly like this (1996-7845 is their ISSN)?

@Ph_We, what are the last numbers? Year and then?
Are these article or issue DOIs?

@bozana, I think, the last number is YYYY-MM-N,
Where N is the running number of articles.

One more example:

Those are article DOIs.

@Ph_We, if I see it correctly, this is: year-issueNo-articleNo (i.e. it seems it is not the month (MM)). If so, this would be possible, you would have to insert the suffix 1996-7845/%Y-%v-%a in the suffix pattern field for articles.
Would those articles be migrated to a clean OJS installation – where there are no other articles of that journal?
It would be good to test it all (together with the migration)… but it seems that everything could work…

1 Like

@bozana, Thank you so much!!

Yes, that would be a ‘clean’ journal migration: we create a new journal in OJS and move its archive into this new journal (so there would be no previous articles or any other content).