After Upgrade to OJS 3.1.2.2: HTTP Error 500 when opening a Journal, Logs attached

Dear OJS Team and Community,
I hope you can help me with this issue.
After Upgrading OJS from Version 2.4 to 3.1.1.4 and then to Version 3.1.2.2 I have a major issue when trying to reach my journals.
They are all correctly displayed on the starting page. However, if i click one and try to get to the corresponding journal overview i get an Internal Server Error.
I looked this up in my error.log and it appears as attached. I can not figure out to resolve this issue on my own.

Best regards,
Nemo Grippa

[Tue Dec 03 14:45:23.996008 2019] [php7:error] [pid 749] [client 127.0.0.1:56670] PHP Fatal error:  Uncaught Error: Function name must be a string in /var/www/ojs-3.1.2.2-mysql/pages/issue/IssueHandler.inc.php:348\nStack trace:\n#0 /var/www/ojs-3.1.2.2-mysql/pages/issue/IssueHandler.inc.php(104): IssueHandler::_setupIssueTemplate(Object(Request), Object(Issue), false)\n#1 /var/www/ojs-3.1.2.2-mysql/lib/pkp/classes/core/PKPRouter.inc.php(390): IssueHandler->view(Array, Object(Request))\n#2 /var/www/ojs-3.1.2.2-mysql/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)\n#3 /var/www/ojs-3.1.2.2-mysql/lib/pkp/classes/core/Dispatcher.inc.php(134): PKPPageRouter->route(Object(Request))\n#4 /var/www/ojs-3.1.2.2-mysql/lib/pkp/classes/core/PKPApplication.inc.php(252): Dispatcher->dispatch(Object(Request))\n#5 /var/www/ojs-3.1.2.2-mysql/index.php(68): PKPApplication->execute()\n#6 {main}\n  thrown in /var/www/ojs-3.1.2.2-mysql/pages/issue/IssueHandler.inc.php on line 348, referer: http://localhost/

Does someone have an idea on this? I am really stuck here.

Hi @ngrippa,

OJS 3.1.2-4 has been released, which addresses this.

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher Can you point to what issue or commit addressed this problem? I’ve run into this same error on only a couple of journals in a multi-journal instances and would like to know more about the root of the problem before upgrading again. Thanks.

Hi all,

This is Journals with subscription support cannot publish · Issue #5315 · pkp/pkp-lib · GitHub. If you prefer, there’s a patch linked there.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,
thanks, upgrading to 3.1.2.4 changed at least the HTTP 500 Error for me. But now I am getting a “DB Error: Table ‘ojs3Db.published_submissions’ doesn’t exist” when I try to reach a journal. I succesfully ran tools/upgrade.php upgrade.

Edit: Okay, I Upgraded to 3.2.0.0 accidently. Should I revert it and try my luck with 3.1.2.4 instead?

When trying to upgrade to OJS version 3.1.2-4 by running the php tools / upgrade.php upgrade command, I get the following error message:
PHP Parse error: syntax error, unexpected ‘?’, expecting variable (T_VARIABLE) in /var/www/html/ojs-3.1.2-4/lib/pkp/classes/notification/PKPNotificationOperationManager.inc.php on line 373

When trying to upgrade to OJS version 3.1.2-4 by accessing the graphical part, the error message is as follows when I try to access the upgrade url:

Esta página não está funcionando

revistastestes.aaa.br cannot fulfill this request at this time.

HTTP ERROR 500

This indicates that you are using an older version of PHP (probably 7.0?).

OJS 3.1.2-2 and later requires PHP 7.1 or better.

/begin gripe
This should have bumped a version other than a patch release
/end gripe

If you have a backup of your original 3.1.1.4 files and database, then yes, I would recommend reverting and re-upgrading to 3.1.2-4.

System Requirements

To run the latest release of OJS 3.x, your web server will need:

The docs in the distributed package read:

I’m guessing you found this outdated info on https://pkp.sfu.ca/ojs/ojs_download/ .

I’ll let the team know so we can update this page.

Note that both PHP 7.0 and 7.1 are end of life. A good target would be PHP 7.2 or 7.3
https://www.php.net/supported-versions.php

Ok, I’ll be testing with PHP version 7.1 or higher, thanks for the help.

Hi @asmecher,
I was able to resolve the issue by upgrading to version 3.1.2-4.
However, if i try to open a PDF of the journal I get a white webpage and the following message appears in my apache log.

 [Tue Jan 07 09:57:38.641152 2020] [php7:warn] [pid 5172] [client 127.0.0.1:39140] PHP Warning:  Declaration of SubmissionKeywordEntryDAO::getByControlledVocabId($controlledVocabId, $rangeInfo = NULL) should be compatible with ControlledVocabEntryDAO::getByControlledVocabId($controlledVocabId, $rangeInfo = NULL, $filter = NULL) in /var/www/ojs3/lib/pkp/classes/submission/SubmissionKeywordEntryDAO.inc.php on line 20, referer: http://localhost/index.php/aa

Any Ideas on this?

Best,
Nemo Grippa

This warning is not enough to cause a blank white page. Look for another message in the same log with the prefix “PHP Error” or “PHP Fatal”.

But that is the only entry in my errror.log

Another less likely possibility is that the screen is blank because of a javascript error instead of a PHP error. Are you familiar with the web browser’s “Inspect” tool to look for javascript errors? Or can you share a link to a page with the problem?

Hi,
the JavaScript Console is completly emtpty on load. The Inspector shows an empty HTML body. Not more.

<html><head></head><body></body></html>

Under Network I recognized two calls. I attached screenshots.

In the apache log an additional Entry apeared. But it seems to apear just once (a day?)

[Wed Jan 08 10:03:25.653719 2020] [php7:notice] [pid 10116] [client 127.0.0.1:41142] Invalid address:  (From): root@localhost, referer: http://localhost/index.php/index

Best,
Nemo GrippaScreenshot%20from%202020-01-08%2010-08-30 Screenshot%20from%202020-01-08%2010-08-18

I would have expected the article/view/2265/6702 call, which is returning a 302, to return a 200 instead.

On the other hand, the article/view/2265/6702 request is what would load the article/download/2265/6702 request, which appears to be returning a 200. So, the “view” request seems to be functioning, though the “download” is an empty text/html response instead of a PDF response.

Does this happen with all PDFs, or only with certain PDFs? Can the PDF galleys which don’t work in the reader interface be accessed in the editorial interface?

Hey,
sorry for the late answer. I could solve this. The Problem simply was, that the PDF couldn’t be found.
The odd thing is, that no 404 Error was returned.
Best,
Nemo Grippa