However, when we deposit this article to Crossref, the deposit fails with the following error:
Error validating schema crossref5.3.1.xsd : Error: cvc-pattern-valid: Value '10.13165/' is not facet-valid with respect to pattern '10\.[0-9]{4,9}/.{1,200}' for type '#AnonType_doi'.
Error: cvc-type.3.1.3: The value '10.13165/' of element 'doi' is not valid.
<?xml version="1.0" encoding="UTF-8"?>
<doi_batch_diagnostic status="completed" sp="ip-10-4-2-147.ec2.internal">
<submission_id>1730306337</submission_id>
<batch_id>_1769014777</batch_id>
<record_diagnostic status="Failure">
<doi />
<msg>Error validating schema crossref5.3.1.xsd : Error: cvc-pattern-valid: Value '10.13165/' is not facet-valid with respect to pattern '10\.[0-9]{4,9}/.{1,200}' for type '#AnonType_doi'.
Error: cvc-type.3.1.3: The value '10.13165/' of element 'doi' is not valid.
</msg>
</record_diagnostic>
<batch_data>
<record_count>1</record_count>
<success_count>0</success_count>
<warning_count>0</warning_count>
<failure_count>1</failure_count>
</batch_data>
</doi_batch_diagnostic>
This indicates that OJS is sending an empty DOI element (only the prefix).
I have verified:
The article is published
The article DOI is correctly set
DOI assignment is manual
Disabling āIssuesā in DOI plugin settings does NOT fix the problem
Hey @Garant, thanks for sharing the details of your issue.
It does seem odd that the āinvalid DOIā finishes with a /.
Could you check in the database (in the dois table for this DOI to see what it has stored in the database? Iām wondering if something went wrong at some point with saving it or if thereās a different bug.
Have you been having problems with other DOIs apart from this one?
mysql> SELECT
s.submission_id,
ss.setting_name,
ss.setting_value
FROM submissions s
JOIN submission_settings ss ON ss.submission_id = s.submission_id
WHERE s.context_id = 6
AND ss.setting_value LIKE '%10.%'
LIMIT 20;
| submission_id | setting_name | setting_value |
| 4207 | doiSuffix | 10.5755/j01.ppaa.14.3.13430 |
| 4210 | doiSuffix | 10.5755/j01.ppaa.14.3.13433 |
| 4211 | doiSuffix | 10.5755/j01.ppaa.14.3.13434 |
As I understand it, doiSuffix should contain only the suffix part,
while the journal DOI prefix (10.5755 in this case) is stored separately
and prepended by OJS during DOI generation.
Is this a known issue when migrating from older OJS versions?
What is the recommended way to fix this for journals with many affected
submissions: manual DB cleanup or is there a supported approach?
Hi @Garant, thanks for sharing. Starting in OJS 3.4, there should be a dois table. Could you see what is showing up there? Also if you go to the DOI management page and look at that submission, is the DOI you mentioned above specified in the field?
Had very similar problem, check this thread please:
And my solution:
Iāve pinpointed the cause in the Crossref log files:
when an article belongs to an issue that hasnāt been assigned a DOI, the OJS plugin sends only the DOI prefix to Crossref. Which naturally is rejected by Crossref.
On Crossref page you can check what exactly what was send to them. Iāve checked those files and noticed that OJS plugin sends DOIs in form https://10.xxxx/ - just prefix with / at the end.
Looked what is happening in my structure and noticed that I want to have DOI for an issue but didnāt assign it yet. Articles were marked as belonging to that issue.
We can confirm the same behaviour:
Crossref deposits started to work only after assigning a DOI to the Issue.
What is a bit surprising is that this happens even when āIssuesā is unchecked
in the DOI plugin settings.
Removing the Issue option did not change the behaviour ā deposits still failed
until an Issue DOI was assigned.
So it seems the Crossref plugin still requires an Issue DOI whenever articles
belong to an issue, regardless of the plugin configuration.
