There is a problem trying to save DOIs when assigning a custom DOI.
The problem occurs when:
I go to edit metadata on an article. So, I click to “Submissions” then locate the article. Then I click to “Metadata” and the form pops up for editing metadata. Then I click to the “Identifiers” tab in that form. Then I enter a “DOI Suffix” and click to “Save” changes.
Through the user interface, this results in a spinner icon in the lower right of the form.
After a very long wait (more than an hour), I get an error message:
“Errors occurred processing this form
The form was not submitted properly.”
On the development server, sometimes the DOI save goes through. When this happens, the spinner icon keeps showing for a long time. If I close the metadata window and then click again to edit “Metadata” I will see that the DOI has saved.
On production, this never goes through. The DOI never takes.
It feels like something is timing out.
Does anyone have pointers on what to look at to try and get it to where journals can consistently add custom DOIs to articles (ie. get the DOI to save and even give a success message instead of just a spinner icon)?
are you using “Enter an individual DOI suffix for each published item. You’ll find an additional DOI input field on each item’s meta-data page.” option? am i correct?
Yes redukr, that is exactly where we are entering the DOI, and then when we go to save, there is a spinner in the bottom right corner of the pop up window, and it spins and spins. Hours later, like if I go back to the tab the next day, there will be an error message.
We looked at httpd and SQL logs, and nothing popped out. Did this on a development server where there is less activity and less in the logs, and kind of looked at log entries near the timestamp of when I clicked the “Save” button.
I am hoping someone has a suggestion for what kind of thing to look for in the error log, or even if someone else had this problem and fixed it. Any pointers at all are extremely welcome. DOIs are essential and it’s a very normal occurrence for journal back logs of articles to have preexisting DOIs that have to be updated manually because they aren’t formatted like the autogenerated ones in OJS.
Hoping anyone has a suggestion of what to look at next to get this fixed?
I think php-curl is enabled. The menu at /index/admin/phpinfo indicates php-curl is enabled. I will try and get a systems adminstrator here to look over php-curl settings and see if anything looks like it could cause the problem.
Most of that issue is about settings in the plugin settings. From the DOI plugin management screen, it’s possible to reassign DOIs to all articles in a journal. Most of the issue #5473 is about that batch reassingment.
There’s a small part where AhemNason describes this problem
"Just tested this and I’m seeing a modal that stays up and inactive when clicked.
had a published article that hadn’t been assigned a DOI
clicked “assign DOIs” from the DOI plugin
opens modal with warning/ok/cancel
can click button, but nothing happens… not frozen, window closes properly when “cancel” is clicked."
Could anyone confirm whether the fix to issue no 5473 [OJS] Assign DOIs action in DOI plugin broken · Issue #5473 · pkp/pkp-lib · GitHub impacts the problem I’m having here. Or could anyone with an OJS 3.1.1-4 install confirm that you have the same problem with not being able to manually add a DOI to a single article, versus do not have that problem?
I’m concerned about whether to focus on trying to get a code upgrade, versus something else like a server setting. The code change in github issue no. 5473 looks promising, but I hope to know before planning to upgrade that an upgrade would fix this specific problem.
So… My biggest problem was solved by optimizing the database. After optimizing the database, this is the behavior in OJS 3.1.1-4 :
When an article is published, and I go to add a DOI at the article level, a spinner spins and spins and spins, and the DOI never gets saved in metadata. I assume that the desired behavior would be that an error message would pop up and tell me that I’m not allowed to add a DOI to a published article, because in the testdrive (as of today the PKP testdrive is on OJS 3.2.0) an error message pops up.
When an article is published, and I go to add a DOI at the article level, a spinner spins and spins and spins. When I close the metadata editing window and reopen it, I can see that the DOI actually did save on the article metadata. (It doesn’t matter whether the article has ever been previously published or not. As long as the article is unpublished when I go to add the DOI, it will save. The bug is that I never get a success message.)
Anyway, optimizing database tables made it possible for me to save the DOI to metadata at the article level as long as the article is unpublished when I go to add the DOI.
I believe that the bug in OJS 3.1.1-4 is that there will never be either an error message nor a save successful message when saving a DOI to metadata at the article level. If anyone could confirm that that’s a known bug and that that lack of a success/error message is what’s fixed in GitHub issue no. 5473, I would be very grateful?
Alec,
The following sql ran in about 4 seconds but it was invoked tens of thousands of times per web request.
SELECT DISTINCT sf.file_id AS submission_file_id, sf.revision AS submission_revision, af.file_id AS artwork_file_id, af.revision AS artwork_revision,
suf.file_id AS supplementary_file_id, suf.revision AS supplementary_revision, s.locale AS submission_locale, sf.*, af.*, suf.*
FROM submission_files sf LEFT JOIN submission_artwork_files af ON sf.file_id = af.file_id AND sf.revision = af.revision
LEFT JOIN submission_supplementary_files suf ON sf.file_id = suf.file_id AND sf.revision = suf.revision
LEFT JOIN submissions s ON s.submission_id = sf.submission_id
WHERE sf.file_stage = ? AND sf.assoc_type = ? AND sf.assoc_id = ? ORDER BY sf.submission_id ASC, sf.file_stage ASC, sf.file_id ASC, sf.revision DESC
We created this index to speed up this query:
create index submission_files_flvc_index
on submission_files (file_stage, assoc_type, assoc_id);
You might want to rename your index so it matches the one in the commits there. so that you don’t end up with duplicate indexes when you upgrade.
As for the volume of queries, that still definitely needs attention. I’ve been doing some work over at pkp/pkp-lib#3304 Replace homebrew caching with Stash by asmecher · Pull Request #5743 · pkp/pkp-lib · GitHub that will hopefully be a partial solution in the future. But as always, if you encounter aspects of the software that are behaving poorly, please post them on the forum as you’ve done for this one – it helps us discover and address bottlenecks, which we might not otherwise encounter.
Regards,
Alec Smecher
Public Knowledge Project Team
