We’re currently encountering an error on OJS where we cannot create a new submission for our journals, new or back issues. What we initially thought was just a plugin issue with our QuickSubmit ([OJS 3.2.1.4] Quick Submit plugin - #9 by charlescmyers) turned out to be all submission formats. We attempted to upload a new submission through the Submission tab, going through all the necessary steps, but got stuck on the exact same step as we did with the QuickSubmit plugin - we cannot upload any files into the galley, it just displays either no option to select it or when we attempt the upload, OJS just shows the loading, spinning wheel without any success.
To attempt to solve our QuickSubmit issue, we attempted to upgrade to the latest version, as seen in the link above, without any luck. Now that we know it’s an issue affecting all submission processes, we hope that there is a solution that we can test out that would address our issue.
Currently, we’ve cleared out all the stage_assignments table, as the error_log showed a duplicate entry, attempted the solutions listed in the link above, and also attempted to upgrade our OJS to the latest version. The upgrade fails and I feel as though it’s related to the issue we’re encountering now.
The original error message we received about the duplicate value:
[02-Aug-2021 18:51:09 UTC] PHP Fatal error: Uncaught Exception: DB Error: Duplicate entry ‘44-2-1’ for key ‘stage_assignment’ Query: INSERT INTO stage_assignments
(submission_id, user_group_id, user_id, date_assigned, recommend_only, can_change_metadata)
I cleared the submissions table but we’re still running into the same issue - when we attempt to create a new submission, the system does not let us upload the Galley file.
A small update regarding this issue that we’re seeing.
Tracking some of the events when the request is sent for the Galley Selection, both in the full submission process as well as the QuickSubmit, brings up the notification menu JS requests, but once the menu is interacted with (to select Article Component), nothing is sent or received. In other words, I think the actual submission notification menu functions correctly and then after that, when it goes to retrieve the next function to actually upload the file, nothing is happening. I also cannot find any errors in our error_log file that would point to anything specific. I’m quite stuck with this.
From what I can see in the upgrade attempts, since I cannot create new submissions currently on the version of OJS that we have installed, the error I’m receiving is as follows:
A database error has occurred: SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL: alter table submission_files add constraint submission_files_file_id_foreign foreign key (file_id) references files (file_id))
When it comes to SQL, I’m quite lost. I could use some assistance with this.
I’ve spent most of the day working within my limited knowledge of MySQL, a fresh install of OJS 3.3.0.7, and a duplicate SQL database to get new error messages!
Specifically, I’ve managed to figure out the following:
The fresh install of OJS has the database engine set as MyISAM instead of what we changed our database to, which was InnoDB. Changing all of our tables to MyISAM pushed the initial script into the next error we encountered.
The next error we encountered was a duplicate value error in our plugin_settings table that I was able to find and delete.
Now, we come to the error I’m encountering when attempting the update:
[06-Aug-2021 13:51:04 America/Chicago] PHP Fatal error: Cannot declare class PKPv3_3_0UpgradeMigration, because the name is already in use in /home/dbqdata/dbqedu/public_html/ojs/classes/migration/upgrade/OJSv3_3_0UpgradeMigration.inc.php on line 666
I’ve reverted our database back to the currently working version of it while I await any help or information on how to move past this issue we’re encountering.
My first guess is that something like a require_once statement is attempting to load PKPv3_3_0UpgradeMigration more than once in some place like the install script here:
I’m not sure what would be causing this, though. What does line 666 of /home/dbqdata/dbqedu/public_html/ojs/classes/migration/upgrade/OJSv3_3_0UpgradeMigration.inc.php as mentioned in the error look like? That may give a hint to what’s going on. Were there any other errors happening around the same time?
Thank you for your response. Line 666 of the file OJSv3_3_0UpgradeMigration.inc.php is the end of the file, as the line is the closing bracket for the file }.
Would it be helpful to paste the file itself? I could paste the rest of the file or host it somewhere for you to view.
The other errors that were occurring around this time are detailed above in the post - duplicate values in the SQL table, errors in upgrading due to the incorrect engine on the table when it would attempt the upgrade, and a few others.
Hmm, that’s curious. Yes, it would be helpful to see the file you’re working with as OJSv3_3_0UpgradeMigration.inc.php should be ~214 lines long. Would you be able to post the file as a Github gist or something like that?
Thanks for sharing that. I’m not sure exactly what’s going on, but it looks like there some strange is happening between the main upgrade scripts for the OJS specific upgrade steps in OJSv3_3_0UpgradeMigration, the shared pkp-lib upgrade steps in PKPv3_3_0UpgradeMigration, and the upgrade.xml document that describes the files and steps of the upgrade process. The original error implies to me that one of these files is acting as the other in way form or another.
To try and pin down what’s going on, could you check the following things in the following places?
In [ojs-root]/dbscripts/xml/upgrade.xml, the last major section toward the bottom should refer to OJSv3_3_0UpgradeMigration and PKPv3_3_0UpgradeMigration in the following way:
In [ojs-root]/classes/migration/upgrade, confirm that:
the upgrade file is called OJSv3_3_0UpgradeMigration.inc.php
the file contains a class called OJSv3_3_0UpgradeMigration that extends Migration
In [ojs-root]/lib/pkp/classes/migration/upgrade, confirm that:
the upgrade file is called PKPv3_3_0UpgradeMigration.inc.php
the file contains a class called PKPv3_3_0UpgradeMigration that extends Migration
Confirm that the contents of both upgrade files are different.
Hopefully this will help get to the bottom of this.
It looks like something’s gone wrong in OJSv3_3_0UpgradeMigration.inc.php as it should have a class called OJSv3_3_0UpgradeMigration. This is where the error about PKPv3_3_0UpgradeMigration being declared twice is coming from.
I replaced the two files with the information in the links you provided and the update went through without any issues. I’m going to check to ensure that I can create a new submission, use the QuickSubmit plugin without problems, and I can mark this as closed on the forums.
Even after applying the update, I’m still unable to create a submission or upload anything through the QuickSubmit. The problem starts when I attempt to upload the Galley - I’m unable to select the Article Component as seen in this image.
I’m unsure what’s causing this, as the last PHP Fatal Error occurring is related to the last attempted upgrade on August 6.
Any assistance on what else to check would be appreciated.
For this newest one, are you able to select anything from that drop down menu?
Also, are you able to add a galley when going through the standard submission process? The only other thing I can think of off the top of my head is to double check that the QuickSubmit plugin is up-to-date for 3.3.
No, the drop-down menu doesn’t have any options to select anything. The standard submission process also returns the same problem - adding the galley PDF in that menu doesn’t allow for us to select anything so we never have the chance to upload the item we’re attempting to work with.
When I performed the update of OJS to 3.3, I had to redownload and upload the QuickSubmit plugin so it is the most recent version.
What is frustrating is that I’m not seeing any error messages anywhere when I attempt to upload the galley. However, I did notice something strange happening when I attempted to upload the galley. In the bottom left-hand corner of my screen, there’s a box that looks as though the system is attempting to bring up a box for something that never quite loads correctly. Any attempt to interact with the box leads me nowhere, as it’s empty and doesn’t do anything. A screenshot is attached, zoomed in to show the box.
Other than the small box in the bottom left, I get no indication of anything throwing errors or causing problems.
As a way of troubleshooting, you could try removing the node_modules directory and rerunning npm install && npm run build.
To look for the cause of the error, could you check your browser’s network tab in the inspector tab? You’ll be looking specifically for XHR requests made when attempting to upload the galley.
Before I started going the route of the node_modules removal, I opened up our OJS site and attempted to get the XHR request information from the submissions tab and the QuickSubmit plugin.
On a completely different computer, I can create the submission without any issues (uploading the file brings the window up and allows me to select a file) but the QuickSubmit plugin returns an internal HTTP 500 error. However, on the primary computer that I utilize, I can use the QuickSubmit plugin AND the standard submissions page without issue but cannot select a file.
This is after upgrading, fresh installing the most recent version of the plugin, and everything. I’ll see what information I can get from my primary computer and the XHR requests there.
As a response to the XHR request that the page is throwing, I found the /json request for the article submission.
GET
https://digitalud.dbq.edu/ojs/index.php/character/$$$call$$$/wizard/file-upload/file-upload-wizard/display-file-upload-form?submissionId=53&stageId=5&uploaderRoles=16-17-4097&fileStage=10&revisionOnly=&reviewRoundId=&revisedFileId=&assocType=521&assocId=108&dependentFilesOnly=&queryId=&_=1630008221512
Status200
OK
VersionHTTP/1.1
Transferred3.80 KB (3.39 KB size)
Referrer Policystrict-origin-when-cross-origin
I was able to get the plugin to work, and able to get back to the submission tab, but I wasn’t able to select a file again, which was the exact same issue I saw before.
Earlier today, we weren’t able to get the plugin to load at all but we could create the submission. Now, we can’t delete the submissions that are created from the earlier attempts to utilize the QuickSubmit plugin. I’ll attempt the node_modules removal in order to rebuild that directory.
Interesting from the PHP error log, as well, is that when I was attempting to load the plugin today, it threw some PHP errors in the system that surprised me.
[26-Aug-2021 15:03:44 America/Chicago] PHP Fatal error: Uncaught Error: Call to a member function getOption() on null in .../ojs/cache/t_compile/cecd5325a2f0fade12ceac8fff391e6ed433f547^e64e579388e5615e11e939b12134d6ae8679eba6_0.app.frontendpagesindexJournal.php:37
Stack trace:
#0 .../ojs/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_612039f7390912_10308795(Object(Smarty_Internal_Template))
#1 .../ojs/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#2 .../ojs/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#3 .../ojs/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(232): Smarty_Internal_Template->render(false, 1)
#4 in .../ojs/cache/t_compile/cecd5325a2f0fade12ceac8fff391e6ed433f547^e64e579388e5615e11e939b12134d6ae8679eba6_0.app.frontendpagesindexJournal.php on line 37
When I couldn’t perform the upgrade, I manually reviewed every table that threw errors looking for duplicate entries, such as this one that popped up when attempting to create a new submission. I’m not sure what to do about this particular error message.
That’s very curious that you’re getting such different behaviour on different machines. I’m not really sure what might be causing that.
For the article component dropdown not working, the XHR request you shared is when the article component is fetched. It looks like it completed successfully, but as you shared, its not returning the proper list. This SQL query might help diagnose the problem, as this is what is internally used to get the list of article components. You could try running this and see if you get a list or it also comes up empty. Swap out context_id = 1 with the journal ID in the database.
SELECT * FROM `genres`
WHERE `enabled` = 1
AND `context_id` = 1
AND `dependent` = 0
ORDER BY 'SEQ';
For the PHP error, it looks like the cached template is trying to run a function on a variable that’s null. If the cached file is still there, you could look at line 37 and see what variable is getOption() is being called on.
Following our conversation, I spoke with my director about what we wanted to do moving forward. I appreciate all of the help that you and the other PKP Team members have given us.
We’re starting with a fresh database and install in order to circumvent the issues we’re running into. I think these issues we’re seeing are being carried over from an SQL database that we (mostly) recovered in April of this year, following a failed update.
As of now, we have a majority of our content uploaded again and will rebuild the journal landing pages instead of attempting to diagnose our issues. I’ll mark a comment as the completed answer so that it closes the thread out.
Thank you again for all your help, I really appreciate the work that the team does to assist everyone.
