@ ctgraham: since I’m new here: is it the same when you answer a question directed at @ asmecher, and when he does?
Within the community forum, we try to encourage everyone to participate in the discussions where they have knowledge and interest. There are many core contributors to PKP, and we will all contribute whenever we can.
Beyond that general rule, asmecher will be largely unavailable for the next week or two.
Thanks.
Why would you say it’s a server issue?! On the contrary, the above fatal errors are obviously due to the QuickSubmit plugin. There are many other cases reporting problems this plugin causes to OJS3.
The right question to ask here seems this: Why is such a buggy plugin included as an official plugin?
I’m looking primarily at the message DB Error: Commands out of sync; you can't run this command now. This is a database error being thrown to OJS. It is plausible that OJS is triggering this by simultaneous queries within the mysqli driver, but if it is an OJS bug, it seems to be very dependent on some unusual external criteria.
What database driver do you have set in config.inc.php and what database system do you use for your OJS database? What OS platform are you running this under?
As asmecher mentioned earlier, the best way to find this error will likely be to see a full stack trace for each of these error messages.
Actually, clearing of caches takes care of that DB error too. As you can see in this thread, others have reported the same error but as related to Announcements, not the QuickSubmit plugin. So the issue seems with the way OJS3 sets cookies, as with many other errors due to OJS3 cookies bug.
All config.in.php settings are OJS3 default. Server configuration and database are all standard, as in 90% users/configurations: Apache, PHP7, etc.
The above errors are from the stack trace in error.log file which started recording the stack trace since show_stacktrace in config.inc.php was turned On per @ asmecher’s advice (it’s also when the white screen (error 500) stopped occurring.)
A stack trace will include all of the function calls leading up to the error, which is why it is helpful for debugging. You can see an example of what one looks like here:
If you can share the stack trace, this will help us to identify the error.
There really is no such thing as a “standard” configuration. Every server has a specific combination of Apache version, PHP version, Database server, and OS version. This specific combination is important for us to know when a bug is found. For example, I’m not able to reproduce this under Red Hat Enterprise Linux Server release 7.6 (Maipo) with Apache 2.4.6, PHP 7.2.14, and the mysqli driver against Ver 15.1 Distrib 5.5.60-MariaDB.
Can you share a link to “OJS3 cookies bug”? Note that only the “Expire User Sessions” option under the Administration menu relates to OJS cookies. Does the problem resolve if you only Expire User Sessions and do not run the Clear Data Cache and Clear Template Cache options?
As I said (twice), the white screen (error 500) is gone since the stack trace was turned on.
Server configuration:
Apache Version 2.4.39
PHP Version 5.6.40
PHP Version (domain) ea-php70
MySQL Version 10.2.25-MariaDB-cll-lve
Architecture x86_64
Operating System Linux
I don’t expire user sessions so it may not be a cookies bug, but it’s certainly an OJS3 bug because I have to clean the system caches in the Admin menu for the bug to go away:
- Clear Data Caches
- Clear Template Cache
So the “DB Error” is gone from the logs as well now? This is what I was hoping to get a stack trace on. Even if you don’t see a white screen, a failed AJAX request would still result in a stack trace recorded in the log.
What is the context of this difference in PHP versions? Note that OJS 3.1.2 requires PHP 7.1 or better.
Again, the DB error is gone from the screen as there’s no more white screen (error 500), and it remains (still appears when triggered) in the error.log only.
The first PHP version is the server’s version (as with all other stated settings). The second one is the domain’s PHP version as set in the MultiPHP Manager of Control Panel 80.0 (build 22). It can be set up to 7.3 and can be different for different domains and subdomains.
Hrm. I thought our fatalError() handler would spit out the stacktrace to the PHP error log as well as to the screen, but apparently not.
If you are comfortable modifying the code, we could change line 117 of lib/pkp/includes/functions.inc.php:
error_log($applicationName.$reason);
if (isset($trace)) error_log(var_export($trace, true));
This should output the stacktrace to the PHP error log.
It is very odd that enabling show_stacktrace would suppress an HTTP 500 error and not print the stacktrace to the screen. I’m very curious to see the call stack here, if you are able to produce it.
Sorry, I don’t have a slightest clue what this is so I don’t feel comfortable doing it if the problem isn’t really a problem (occurs and ends within AJAX). Besides, it could be that I missed something when describing the problem as I’m not an expert/developer. Also, the error is not easily reproducible, sometimes it can be reproduced but sometimes it can’t.
But I remembered something while looking at your thread link above: the error.log once (days ago) did record a message similar to this one proposed in that thread: “to solve this problem you have to store result data before use it” although I’m not sure if it was also a fatal error or a warning. Hope this helps.
So you think that PHP version 7.0 is OK although the recommended PHP version for OJS3 is 7.1 ?
No, PHP 7.0 is beyond end of life:
https://php.net/supported-versions.php
PHP 7.1 is the minimum supported version.
But if I remember it correctly (this was a couple of months ago), we can’t run some plugins under PHP 7.1, like ORCID, OpenAIRE… they crash the whole site.
I know the orcidProfile plugin is designed for PHP 7.1 or better.
I searched the forum for issues with OpenAIRE and 7.x, but didn’t see anything relevant. Since it is packaged with OJS 3.x by default, it should be compatible as well.
OK, we’ll retest PHP 7.1 then. Perhaps all sorts of patches that you guys came up with in the meantime have fixed the issues I was referring to. Speaking of plugins, is there a directory of current (stable or not) plugins, like WordPress has?
Since asmecher is unavailable, can you address these pressing (monetary) issues addressed at him: here and here.
Most importantly: how are manual payments actually integrated with OJS3? User Manual is very general and doesn’t cover this issue. Is there some technical documentation? For example, how does an unsubscribed buyer who manually purchases a single article access just that article (with and without creating a user account)? I searched everywhere but to no avail.
The Plugin Gallery within the application is intended to be the standard for the directory of current plugins, but this is obviously not exhaustive. You’ll find a number of others listed here in the forum. I think that ultimately a parallel to WordPress’ plugin directory or Drupal’s module list would be nice.
I can try to look at the linked issue if other folks don’t chime in. My emphasis is on open access publishing, however, so I’m not as familiar with the payment code.
OK. And do you have a fix for the above strange mousover behavior that just looks unprofessional?
In the meantime, could you please also address these two issues:
-
When search returns some results, and you hit the Back button on your browser (here Chrome), you’re taken to this ugly Confirm Form Resubmission page:
Is there any way to bypass it and take the visitor back to the Search form directly? Another forum has a whole bunch of proposed solutions, so perhaps you could find the one that’s fitting for the OJS3? -
When viewing an article in the Article View, you’re presented with article Title, Authors, Affiliations, Abstract, How to Cite, Issue, Section, Copyright, and References sections of the View. How do we make the article’s displayed Section (for example: “Research Articles”) clickable so that clicking it takes the visitor to our Research Articles section? I think this added cross-referencing feature is simple to implement (and based on your previous help above, I’m sure you already know where to find it and how to make it clickable). It would greatly improve the user-friendliness of the OJS3 and provide a better user experience. So perhaps this might be worth a new feature in a future OJS3 upgrade. (This is for us who installed the Browse by Sections plugin.)
Please open each of these as new topics, if you haven’t already.
OK, just did, here and here. Please address them, if you would?
The issue of strange mouseover behavior as depicted above still needs attention/solution.