Hi! I have two questions:
- What can trigger metadata update in the CrossRef module? Does it make it automatically? Is this procedure scheduled?
- How could we manually enforce metadata update (for all articles in a specific journal)?
Sorry for duplicating and repeating this, but we really need an urgent help. The problem is this: we are testing the OJS 3.1.2. So we have two instances installed and working: 3.1.1-4 (production) and 3.1.2 (test).
Recently we’ve noticed that the CrossRef plugin in 3.1.2 (test) seems to have updated metadata automatically for a certain journal. So all the DOIs at the production site now resolve to our test site 
The question is whether it is some new logic in the CrossRef API/module, which causes such behavior? What may trigger it? (such problem is observed only for one journal). How could we revert this back?
It’s really annoying, since CrossRef seems to regard those issues/articles as new ones and now is trying to bill us for them!
UPD: We’ve managed to manually resolve the problem with metadata by submitting all the articles again. But we would still like to know more about the logic of CrossRef module metadata updating.
By submitting them again were you double billed by Crossref? We are trying to update the metadata for few articles and are not sure if submitting it again would be considered as a new submission.
As far as I understand (my colleagues), we only received notifications from Crossref, that those issues were registered from another OJS instance/site. However, since we closed that site and re-registered them again from the main one, we have never been billed twice.
Anyway, any additional information on the principles of the Crossref plugin updating would be still much welcomed. 
I’m not aware of anything that will automatically trigger a metadata update for objects which OJS thinks are already registered with CrossRef.
The most likely scenario I can come up with is that if you had an issue which was published and registered with CrossRef in your production system, but was not published and registered in your development system, and if you published that issue in the development system and had automatic registration active there, the development system would then re-register the DOIs in CrossRef, thinking they had never been registered. This would effectively be an update.
1 Like
Thank you! Am I right that you think no automatic updates are possible even if any metadata are changed?
That was surely not the case. The CrossRef plugin began updating everything for that journal the day when the test 3.1.1-4 instance was updated to 3.1.2. All the journals stayed intact during that day (and 3 days after that).
So the only possible explanation I have is that the CrossRef plugin somehow ‘thought’ the metadata had changed. Since the URLs registered previously were not the same.
The general way that the plugin works is to examine all published but unregistered articles, checking to ensure they are eligible for registration. These are then processed for registration. Registration adds an article level setting indicating the registered DOI and the registration status.
Because of this, with a completed registration, the object should not be reprocessed unless you specifically tell the plugin to re-register the objects via the UI.
For one other possibility, could it be that the objects were registered in a previous release of OJS, but when the development system was upgraded to 3.1.2, and something in the upgrade process corrupted the article settings? If this was the case, you should be able to reproduce the error with a new upgrade of a fresh copy of your production environment. (Be sure to prevent actual re-registration by changing to the test API endpoints or blocking external requests to CrossRef.)
1 Like
Thanks, @ctgraham, the whole procedure seems to me much clearer now.
However, the issue itself is still kind of enigmatic, since we did not get any errors, which might have indicated something went wrong with the articles settings. What is the most perplexing is that only one journal (out of ~13) got updated in that way.