Describe the issue or problem
We have recently upgraded our OJS site to the latest version and since then our new DOIs are not working properly. The DOIs are being assigned, but are not being registered in mEDRA. We have already tried all and today we decided to uninstall and reinstall the mEDRA plugin.
When we reinstall the plugin we are given the following message:
After this we have noticed the plugin is not installed.
Prior to that, it were impossible to register any data and we were given the following message:
mEDRA: 500 - uploaded file is not valid: cvc-pattern-valid: Value ‘_ref1’ is not facet-valid with respect to pattern ‘10.\d*/\S*_ref\d+’ for type ‘#AnonType_keyArticleCitation’.
We could not directly export the data either.
We have checked with our hosting for any problems related to permissions, but everything seems ok.
What application are you using?
OJS 3.3.0-4
DOI to mEDRA XML export and registration plugin 4.0.0.1.
Just to double check: in your database table versions you do not have an entry/row where product = ‘medra’ and product_type = ‘plugins.generic’ ?
I think I know what is the problem: Because you do not have the entry in the DB table versions, when you try to install the plugin, a migration script is run. The migration script should be actually run only once, when the plugin is first installed, but because you have deleted the plugin (so there is no entry in the DB table version) it is run again, because it thinks it is the first time.
I found a bug in the migration script – some submission settings were not deleted correctly, so that now, when you run the script second time, that error occurs – it tries to insert something that is already there.
I will fix that and release a new plugin version, that you then can install.
Regarding the other problem that you had:
mEDRA: 500 - uploaded file is not valid: cvc-pattern-valid: Value ‘_ref1’ is not facet-valid with respect to pattern ‘10.\d*/\S*_ref\d+’ for type ‘#AnonType_keyArticleCitation’.
This means that the XML is not valid. This problem will probably appear again, after you have installed the plugin anew. Then please ask me the question in this forum again – we would then need to find out what is the exact value for that reference/citation and to see how to solve the problem.
You can find the XML file that is exported and then sent to mEDRA in your files folder, in the folder tmp/. You can then copy the XML or the part that contains citations (cl:CitationList) here, so that I can see it…
I will let you know when the new plugin version is published…
Finally I have been able to install the plugin, thank you very much! I have tried to deposit a DOI to see if it works properly. I have not been able to export the xml file for the moment though, should I open a new topic or should I explain it directly from here?
Great!
I think the registration will fail as well, if you could not export it.
Could you try to export a DOI and then take a look in that most recent XML file from the tmp/ folder in your files folder on the server? Could you send/copy that file to me here?
Yes, I was into it. I hope you’ll find the problem. I send two docs: one refering to an article and one refering to a book review. I attach both of them because the book review does not have any references, but still unable to export it. I don’t know how to attach an archive in a reply, so I madre a google drive folder here.
I found a bug in the code, in the citation export. The function that tries to get article DOI to construct the reference element key attribute is old/does not exist any more. I will fix it, and will again let you know when a new version is there so you can upgrade the plugin.
I see you have the sign “-” everywhere in your citations. Also the headings, e.g. “FUENTES DIGITALES” and “BIBLIOGRAFÍA”. Having them like this leads to other services (e.g. mEDRA) having wrong/unclean data. Actually, in the OJS’s reference field only references, line by line, should be entered.
Regarding the book review example: it seems you only have the sign “-” in the reference field, so it is parsed as a reference – the system is not intelligent, it only parses the reference field line by line, assuming the reference is correctly entered in one line – every line in the reference field is assumed to be a reference. Thus, you have one reference, containing only “-”. Could you double check this? Eventually you would also like to correct your references, or at least for the future…
Thank you very much for all your help. I will be attentive to the new patch.
Regarding the references, I really appreciate your comments. We never really knew how that metadata field exactly works, but I began to understand it when I checked the .xml and registered one DOI manually. I see what you are pointing out and we will correct that from now on and we will correct the older references eventually.
Great!
The new plugin version 4.0.0.3 is released, so you can do the upgrade via the plugin gallery.
Please let me know if the export/deposit works then…
I have installed the plugin and I can finally export the DOIs, but it seems that it still has issues with the deposit. I deposited one yesterday and some others today, unpublishing and pubishing them again and I re-checked the plugin settings to kind of force that the plugin logs in with my user/pwd, but the DOIs are not registered for the moment. I attached the new exports to the drive in case you need them.
I’ll wait for your comments. Thank you very much again.
Sorry for the lack of info. When I choose “deposit DOI”, it is marked as “Submitted”. I tried this yesterday to see if it’s changed to “Registered” within the next 24h. I didn’t receive any email from mEDRA like it used to when I register one DOI properly, so I assume it is not working as far as mEDRA told me this process should be resolved almost automatically.
Regarding the setup, it should be filled correctly, indeed: Setup
DOIs: checked
Items with DOIs: Article
DOI prefix: checked
Automatic DOI assignment: Upon publication
DOI format: Default (before the upgrade we had marked “Custom pattern”)
Registration
Registration Agency: mEDRA
Automatic deposit: checked
mEDRA settings: all checked
Deposit to Crossref and Testing: not checked
Maybe it is because the last DOIs are already published? Or maybe it is for have changed the DOI format?
It all seems to be OK.
Now, the DOIs are deposited using so called Jobs. First the DOIs are put in a job queue, then the job is run to send them to mEDRA.
Could you please login as admin, then go Administration > Jobs > View jobs and View failed jobs. Do you see any job or failed job since the last try to register a DOI?
I’ve entered and see no jobs or failed jobs. Then I’ve tried to register a DOI and immediately checked. I get like 4 or 5 jobs, some of them with 2 attempts. Then I’ve checked failed jobs and there’s none and when I came back to check jobs, they are all gone.
Should I assume it is working properly but it simply may last a few days?
I have some news. The DOIs are still not registering in mEDRA and I recently had a meeting with Paola from support to see the process directly. Apparently, the submissions do not reach mEDRA endpoint (there’s no trace of them). When I deposit a DOI, some attemps occure and then they are immediately shown in failed jobs. I attached another screenshot so you can check.
Yes, that was what I was also thought about – that the job that sends the DOIs to mEDRA fails. Could you please click on the Details button for such a failed job and copy for me what you see there?
Hmmm… This issue is a little bit more complicated – I do not understand why it is happening
It seems that when the job (to deposit submission) is run, the MedraExportPlugin cannot be found. But when you use export function, you can export the XML file, which means that the MedraExportPlugin is then found. Let me check with my colleague that knows more about jobs.
Maybe one question for the system admin: how are you jobs run? – Do you have AcronPlugin enabled?
See this documentation: https://docs.pkp.sfu.ca/admin-guide/en/deploy-jobs. Per default the Built-in Job Runner is used. I assume this is the case for your installation, but to double check that Cron job or Worker (from that documentation) are not used.
Also, how are your scheduled tasks run? – Again, is there maybe any extra Cron job that you are using for it?