Hi,
I see a number of issues related to the ORCID plugin on the Forum, but none seem to be quite what we are experiencing.
We are running OJS 3.2.1.1 on RHEL 7.9 with Mysql 5.5 and ORCID plugin 1.1.2.7 installed via the Plugin Gallery.
We have put our ORCID credentials in the config.inc.php file.
Attempts to configure the plugin fail with ‘invalid client ID’, ‘invalid secret id’ and the API type switches from Member to Public.
If we simply enable the plugin without trying to do further configuration, it appears to work as expected. If we remove the credentials from config.inc.php and put them in the plugin configuration dialog, then configuration succeeds without errors.
Has this issue already been flagged by other institutions?
Without sharing any of your configuration, can you confirm if you’ve added the necessary [orcid] tag to the beginning of your ORCID information, and that you’ve placed this down at the bottom of the file after all of the other configuration blocks? I am wondering if the plugin just isn’t loading your configuration because it can’t find it.
Hi Jason,
Thanks for the suggestions. I can confirm that the [orcid] tag is there and that it is at the end of the file. The plugin is able to find the credentials because they are displayed in the plugin configuration dialog, and the functionality the plugin provides works as expected. The problem seems to occur only if we try to save configuration settings in the plugin dialog. When we click Save, the credentials that were displayed disappear, the API type changes from Member to Public, and we see messages regarding invalid credentials.
Hi all - An institution I work with is having the exact same issue with site-wide configuration of the ORCID-OJS plugin. They have OJS 3.1.2.1 with ORCID plugin version v1.1.1.12 released 2021-02-28.
I have checked your scenario and can reproduce it.
When configured in the site-wide modus, orcid Plugin is not allowed to be set manually. It shows the error you described. I will disable the first saving the settings for the global configuration as an immediate measure and later allow individual savings for logging erros and setting email type in a future version.
Actually, the workaround is that : after you have had the false public setting, you have seen the plugin got disabled, right ? Then you have to re-enable the plugin from the plugin list. It should be then automatically re-enabled with site-wide settings.
Thanks for the information and video, @Dulip_Withanage. However, we are still experiencing issues with our OJS version 3.1. We will keep this in mind once we upgrade to version 3.3.
A secondary issue to this is that users are not able to change their settings - for example in this case, if you wanted to disable the email checkbox, there is no way to do that, even with this workaround. The changes never get saved because of the error.
@kaitlin Hi Katlin, yes, you are right. For changing the other settings, the workaround would not save that. i am planning to add this featue in a future version as mentioned above
We have exactly the same problem (we are using OJS 3.3.0.6, but have not upgraded the Orcid plugin to v1.1.2.19 released). So if I understand correcty the workaround allows to activate the plugin but does not allow to change the E-Mail Settings or the ORCID request log. Those config will stay with their default value (uncheck for the E-mail setting, Error for ORCID request log). Am I correct?
Hi @pilas , Couple of weeks ago, I released a version in the plugin gallery, which disables individual settings for journals in orcid settings , thus not allowing to create errors for multi-journal installations.
See image with “save” disabled.
I know, this is not the perfect solution, but minimizes JM/Admin config errors.
In a future version, I will allow global configuration of mail settings for the site-wide settings.