[OJS 3.2.0.3] Error on Submission Page

Hello,
I’m in the process of updating several of our hosted OJS Journals to newer versions.
After Updating Journals to 3.2.0.1 and 3.2.0.3 I have encountered Errors when opening the Submissions page:

  • A popup containing “unexpected error” appears three times (similar behaviour as in other threads).
  • The Submissions page is not loading any content.
  • The rest of the page works as normal.

The following error shows up in the log:
PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function APP\Services\SubmissionService::getInSections(), 1 passed in /var/www/ojs_3203/plugins/generic/webFeed/WebFeedGatewayPlugin.inc.php on line 122 and exactly 2 expected in /var/www/ojs_3203/classes/services/SubmissionService.inc.php:151\nStack trace:\n#0 /var/www/ojs_3203/plugins/generic/webFeed/WebFeedGatewayPlugin.inc.php(122): APP\Services\SubmissionService->getInSections(‘32’)\n#1 /var/www/ojs_3203/pages/gateway/GatewayHandler.inc.php(230): WebFeedGatewayPlugin->fetch(Array, Object(Request))\n#2 /var/www/ojs_3203/lib/pkp/classes/core/PKPRouter.inc.php(391): GatewayHandler->plugin(Array, Object(Request))\n#3 /var/www/ojs_3203/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)\n#4 /var/www/ojs_3203/lib/pkp/classes/core/Dispatcher.inc.php(143): PKPPageRouter->route(Object(Request))\n#5 /var/www/ojs_3203/lib/pkp/clas in /var/www/ojs_3203/classes/services/SubmissionService.inc.php on line 151

Any idea what causes this and how it could be resolved?
Thanks!

Hi @KBodarwe,

Did you upgraded plugins also? According to the error, webfeed plugin code corresponds to 3.2.0.1 OJS version.

Hello Vitaliy,
thanks for the answer. Is there a quick way to check the plugins?
I did a fresh 3.2 installation. The only plugins I add are two which correspond to the looks of the page. After deactivating these two the journal is in stock configuration.

Also this error log is probably from a 3.2.0-1 installation. Was the error fixed in 3.2.0-3?

Yes, I can confirm that it’s fixed in 3.2.0-3.

Hello @Vitaliy,
I have upgraded both my 3.2.0-1 Installations to 3.2.0-3 and the problem persists.

The error log now shows the following error three times:
[Fri Jun 05 15:32:46.200626 2020] [php7:notice] [pid 3511] [client 132.199.243.39:35912] ojs2: 404 Not Found, referer: http…

In the other installation the Errorlog is inconclusive.

Does the error from the web feed plugin persist?

Can you describe when this error appears? What’s the full message?

Hello,

the WebFeedError is no longer there, it’s replaced by the one I mentioned.

The Error appears when opening the submissions page. The Popup opens three times, like mentioned above. The log coincides with the error on one journal, on the other no error log entry is made but the error appears to be the same on the front end.

The full error log entry is:
[Fri Jun 05 17:03:34.929330 2020] [php7:notice] [pid 3725] [client 132.199.243.35:55112] ojs2: 404 Not Found, referer: http://journalurl/submissions
[Fri Jun 05 17:03:34.972423 2020] [php7:notice] [pid 3724] [client 132.199.243.35:55108] ojs2: 404 Not Found, referer: http://journalurl/submissions
[Fri Jun 05 17:03:34.982762 2020] [php7:notice] [pid 3729] [client 132.199.243.35:55110] ojs2: 404 Not Found, referer: http://journalurl/submissions

I do have a .htaccess configured for both journals, that cuts out the “index.php/journalname” part of the URL:

RewriteEngine On
RewriteBase /

# Rewrite URL to look cleaner
RewriteCond %{SERVER_NAME} ^www.journalurl
RewriteCond %{REQUEST_URI} !/journal/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/journal/$1 [L]

Looks like a controller for a submissions page isn’t found. Yes, it’s likely because of URL rewrite. Did you check through the forum needed configurations in ojs config and apache requests redirecting/remapping? e.g.: How to remove index.php in ojs 3.0.2.0.

Hello Vitaliy,

I seem to have found the problem, but I have no Idea on how to fix it.

the .htaccess is set to cut “index.php/journal/” from the URL. I do this, because I don’t want users to see the “/journal/” part in the URL and because I am upgrading older journals, that have a lot of DOI links to the URL without “/journal/” from older OJS 2 times.

If I cut “index.php” only from the URL, the submissions page works fine. Every other pages do too, but my DOI links are broken.
If I cut “index.php/journal/” from the URL, the submissions page doesn’t work. Every other page does.

Is there maybe something in the submissions page, that calls explicitely to the “journal” part in the URL?

Thanks and Greetings.

Yes, as far as I remember in many parts of the code Journal (or Context) is retrieved from a request. I don’t think that it would be possible to cut the journal from the URL without code modification. First, I would check if this method works properly: pkp-lib/PKPRouter.inc.php at c512bf148e43b8beafed90879200aa9b67807d93 · pkp/pkp-lib · GitHub
(if it return the context).

Also it’s possible to make journal invisible to the public from the dashboard → administration → hosted journals → edit button

Hello Vitaliy
I don’t quite know how to test if getContext is working.

From the browser debugging tools, it seems that a.pkp.controllers.modal.ModalHandler.prototype.modalOpen is throwing errors:
grafik

grafik

Hello,

I am still having problems with this error. Do you have any other ideas as to what may cause this?

Thanks!

Hi @KBodarwe,

As I wrote before, I’m not sure if PKPRouter::getContext will work if URL is missing the context part. Take a look at developer’s docs: Routes - Technical Documentation - OJS|OMP|OPS, context part points to the journal in OJS. Let’s assume that context is missing, how would Router determine the current context?

You can try to debug, not sure what debugging approach are you using, but the result can be simply written in the logs, e.g., error_log(print_r($yourVariableHere, true)).

Referred JS error just indicates that the element there should be in the DOM is missing.

1 Like

Hi,
I am also waiting for a solution for the error when the context path is removed via mod_rewrite.
There is an issue on Github at this link and I am following it. I removed my customization on journal path and updated all DOIs via DOI plugin.
API calls fail if context path is obscured by RESTful URL configuration
Regards.,

Hi, we are seeing the same issue as well when opening the Submissions page (a popup error appears three times) with OJS 3.2.0.3. The page seems to load the content correctly after the errors are dismissed. The error does not appear with previous versions of OJS e.g. 3.1.2.x.

It appears that it’s to do with the URL rewrite that we have in place to remove “index.php/journal” so that it’s not visible to users.

If we don’t do the rewrites i.e. URL becomes “https://server/journal/index.php/journal/submissions”, the errors don’t pop up when accessing the Submissions page.

1 Like

I have tried to insert a Redirect into my .htaccess that redirects the submissions page to show the correct URL.
i.e.:

RewriteEngine On
RewriteBase /

RewriteRule ^submissions(.*)$ index.php/journal/submissions$1 [R,L]
RewriteRule ^stats(.*)$ index.php/journal/stats$1 [R,L]

RewriteCond %{SERVER_NAME} ^www.server.de
RewriteCond %{REQUEST_URI} !/journal/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/journal/$1 [L]

Now the correct URL gets shown when accessing the submissions page, but the error still persists. Any Idea why that didn’t fix it?
Thanks!

Update: I tried this approach:

RewriteEngine On
RewriteBase /

# Bugfix for OJS 3.2.0-3: submissions API doesnt work with shortened URLs
RewriteRule ^api/v1(.*)$ index.php/journal/api/v1$1 [R,L]

# Rewrite URL to look cleaner
RewriteCond %{SERVER_NAME} ^www.server.com
RewriteCond %{REQUEST_URI} !/journal/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/journal/$1 [L]

and it works.

The re-routing of the API seems to work.

1 Like

This is brilliant KBodarwe. I’ve tried adding the line…

RewriteRule ^api/v1(.*)$ index.php/journal/api/v1$1 [R,L]

…and it’s working perfectly with our existing URL rewrites for OJS 3.2.0.3 based journals.

Thanks for sharing!

Some more information on this can be found in this GitHub issue:

Hi @KBodarwe
Thank you very much for your contribution. I have tested your solution on my test domain, and can confirm that it works very well. I applied it to my live site and will update all DOI records now.
Best regards,