Certain Editors receive blank page on click submissions in their dashboard

Software Support
1

We got a message from two editors that reported that they could log in and use some features of their editor level access, but that for journal/submissions they were getting blank pages back from the site, e.g., when clicking submissions in their dashboard menu. Other parts of their access are fine, such as announcements. Importantly, one is the principal contact for the journal.

It works fine for me as an admin. Another admin tried and it works for her. If we log in as either of the two users on an article we know they are editors for, we can actually replicate the blank page that’s returned, too! The blank itself returns only this console error to clients:

> Uncaught SyntaxError: Unexpected token '<'

Its plugins don’t stand out as different than other journals and we’re not getting widespread reports of others with this issue. Any suggestions on what/where to investigate?

2

Hi @dwm,

Are you able to check your PHP error logs? That can often provide more clues than a console log. Also, can you please indicate your OJS version (e.g. 3.3.0-13)? In the future, please include this in your posts, as it assists others in helping to troubleshoot.

-Roger
PKP Team

4

Absolutely, @rcgillis. I’ll remember for next time! We’re running 3.4.0.3.

Today we got reports of more odd behavior when a journal’s login button broke in a weird way. It began to redirect to a Google search with “undefined” (as in undefined journal, I think) and then all of the journal’s meta tags as keyword searched.

I don’t have access to the php logs yet, but I should soon and will re-update and this and potentially file that second issue separately. I’ll dm you a link so you can try that bug yourself.

6

I have an update on things to share on our issues with the submissions page. Journal team members are still encountering the bug, which prevents specific logged in editors from seeing their own /submissions endpoint, even as the items in the workflow remain accessible invididually by url. They are met with a blank page instead. I can cite a specific user and journal where we can replicate the error internally.

After reviewing the recent error.log, I updated some plugins that were causing assorted issues for specific journals. But site-wide I see some things that stand out and I wanted to highlight the ones related to inaccessibility of the submissions page, so for instance:

[Thu Nov 09 14:48:03.727841 2023] [php:notice] [pid 80505] [client 94.11.208.164:0] Exception: Plugin lensGalleyBits expected to inherit from LensGalleyBitsPlugin, actual type NULL in /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203\nStack trace:\n#0 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(219): PKP\\plugins\\PluginRegistry::_instantiatePlugin()\n#1 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(112): PKP\\plugins\\PluginRegistry::_loadFromDatabase()\n#2 /var/www/ojs/lib/pkp/classes/core/Dispatcher.php(155): PKP\\plugins\\PluginRegistry::loadCategory()\n#3 /var/www/ojs/lib/pkp/classes/core/PKPApplication.php(387): PKP\\core\\Dispatcher->dispatch()\n#4 /var/www/ojs/index.php(21): PKP\\core\\PKPApplication->execute()\n#5 {main}, referer: https://journal.equinoxpub.com/JMBS/submissions

and

9528  [Thu Nov 09 15:20:09.172651 2023] [php:notice] [pid 81474] [client 80.208.65.144:0] Exception: Plugin allowedUploads expected to inherit from AllowedUploadsPlugin, actual type NULL in /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203\nStack trace:\n#0 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(219): PKP\\plugins\\PluginRegistry::_instantiatePlugin()\n#1 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(112): PKP\\plugins\\PluginRegistry::_loadFromDatabase()\n#2 /var/www/ojs/lib/pkp/classes/core/Dispatcher.php(155): PKP\\plugins\\PluginRegistry::loadCategory()\n#3 /var/www/ojs/lib/pkp/classes/core/PKPApplication.php(387): PKP\\core\\Dispatcher->dispatch()\n#4 /var/www/ojs/index.php(21): PKP\\core\\PKPApplication->execute()\n#5 {main}, referer: https://journal.equinoxpub.com/JCSR/submissions

Similar errors sometimes appear in user workflow endpoints:

9541  [Thu Nov 09 15:20:27.677533 2023] [php:notice] [pid 81511] [client 80.208.65.144:0] Exception: Plugin allowedUploads expected to inherit from AllowedUploadsPlugin, actual type NULL in /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203\nStack trace:\n#0 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(219): PKP\\plugins\\PluginRegistry::_instantiatePlugin()\n#1 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(112): PKP\\plugins\\PluginRegistry::_loadFromDatabase()\n#2 /var/www/ojs/lib/pkp/classes/core/Dispatcher.php(155): PKP\\plugins\\PluginRegistry::loadCategory()\n#3 /var/www/ojs/lib/pkp/classes/core/PKPApplication.php(387): PKP\\core\\Dispatcher->dispatch()\n#4 /var/www/ojs/index.php(21): PKP\\core\\PKPApplication->execute()\n#5 {main}, referer: https://journal.equinoxpub.com/JCSR/workflow/index/27225/1

Some have no referrers:

[Thu Nov 09 18:06:47.464247 2023] [php:notice] [pid 87014] [client 66.249.73.129:0] Exception: Plugin allowedUploads expected to inherit from AllowedUploadsPlugin, actual type NULL in /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php:203\nStack trace:\n#0 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(219): PKP\\plugins\\PluginRegistry::_instantiatePlugin()\n#1 /var/www/ojs/lib/pkp/classes/plugins/PluginRegistry.php(112): PKP\\plugins\\PluginRegistry::_loadFromDatabase()\n#2 /var/www/ojs/lib/pkp/classes/core/Dispatcher.php(155): PKP\\plugins\\PluginRegistry::loadCategory()\n#3 /var/www/ojs/lib/pkp/classes/core/PKPApplication.php(387): PKP\\core\\Dispatcher->dispatch()\n#4 /var/www/ojs/index.php(21): PKP\\core\\PKPApplication->execute()\n#5 {main}

I know that allowedUploads is an independent plugin. It’s possible the site could have used this previously. I’ll check with others that have been here longer. I can say that it does not appear in the current plugin gallery for the site or any journal that I’ve checked thusfar. Following this suggestion, I’ll head to our database to see if I can find what’s leftover and causing this ruckus.

And apologies to @rcgillis, whom I accidentally dm’d instead of posting here.

7

I’m bumping this again since I have resolved the php errors above and the problem persists.

The /submissions endpoint is failing for some, but not all, users. EG, a user like me who is a copyeditor for a journal with active items in the workflow receives a blank page. Same is true for managing editors and section editors for other journals, with very little pattern we can discern except that we can clearly replicate the error when logged in as those users. Other journals where I have no responsibilities are fine. Others we tested by adding ourselves into the editorial team didn’t reproduce the blank submissions issue.

Now, visting /submissions no longer generates any php errors. Instead, from the website’s perspective all the data seems to be there in the html, including appropriate menus, details about articles, etc. All 200s across the board.

So perhaps this is a visual-only bug, and if so I wonder if it ties to my very first post, an errant “<” being generated by submissions:500, which is the following open issues from this function:

public function convertFromDB($value, $type, $nullable = false)
{
if ($nullable && $value === null) {
return null;
}
switch ($type) {
case 'bool':
case 'boolean':
return (bool) $value;
case 'int':
case 'integer':
return (int) $value;
case 'float':
case 'number':
return (float) $value;
case 'object':
case 'array':
$decodedValue = json_decode($value, true);
// FIXME: pkp/pkp-lib#6250 Remove after 3.3.x upgrade code is removed (see also pkp/pkp-lib#5772)
if (!is_null($decodedValue)) {
return $decodedValue;
} else {
return unserialize($value);
}
// no break
case 'date':
return strtotime($value);
case 'string':
default:
// Nothing required.
break;
}
return $value;
}

What we see in the html when exectued looks like this, slightly truncated to exclude the json:

<script type="text/javascript">
		pkp.registry.init('app', "Page", <br />
<b>Deprecated</b>:  json_decode(): Passing null to parameter #1 ($json) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>333</b><br />
<br />
<b>Deprecated</b>:  unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>338</b><br />
<br />
<b>Deprecated</b>:  json_decode(): Passing null to parameter #1 ($json) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>333</b><br />
<br />
<b>Deprecated</b>:  unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>338</b><br />
<br />
<b>Deprecated</b>:  json_decode(): Passing null to parameter #1 ($json) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>333</b><br />
<br />
<b>Deprecated</b>:  unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>338</b><br />
<br />
<b>Deprecated</b>:  json_decode(): Passing null to parameter #1 ($json) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>333</b><br />
<br />
<b>Deprecated</b>:  unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in <b>/var/www/ojs/lib/pkp/classes/db/DAO.php</b> on line <b>338</b><br />
{JSON});
</script>

All advice is appreciated!

8

Hi @dwm,

It looks like you’ve got errors and/or warnings directed to the browser rather than the log. This could be either your PHP configuration (e.g. display_errors, or your OJS configuration (display_errors, deprecation_warnings), but in any case, you can resolve the problem by directing errors/warnings to the PHP error log instead. It’s not recommended to direct errors/warnings to the browser – it can reveal private information!

Regards,
Alec Smecher
Public Knowledge Project Team

10

You nailed it. Functionality is restored. Thanks again!

1 Like