When we (content editors) try to send messages from within the OJS system (including both when assigning reviewers and when communicating with authors in sections like “pre-review discussions”), we get a spinning progress wheel that doesn’t resolve. If I hit “refresh,” there appears to be a record of the message/action on my end–but it seems that recipients are not receiving the messages.
The only things I’ve tried so far are the very basics:
Clearing cache
Using a different browser (and logging on both at work and at home)
This is happening for both of us who are primarily responsible for communicating with authors, reviewers, and other associate editors.
I don’t see this specific kind of message elsewhere in the forum; apologies if I’m not finding an existing thread (and hopefully solution!).
Hi @pjaw_tech,
For the spinning wheel syndrome, or effectively anything that occurs when OJS does not complete an operation as expected, it is always best to check your PHP error log, as the error messages there provide more clues as to what the specific error is. If unsure of how to do that, please have a look at this post here: How do I find my PHP error log?
Feel free to report back on any error messages you find in your log(s).
-Roger
PKP Team
Hi Roger. Here’s what I was able to learn from the tech support at DreamHost, where our version of OJS is hosted:
I also reviewed the error.log for [our journal’s site] and did see
these entries:
[Thu Jan 30 04:48:22.256066 2025] [fcgid:warn] [pid 2733438:tid
139719249733184] [remote 40.77.167.59:21071] mod_fcgid: stderr: PHP Fatal
error: Uncaught Error: Call to undefined function import() in
/home/[user/journalname]/lib/pkp/classes/user/form/IdentityForm.inc.php:16
[Thu Jan 30 04:48:22.256168 2025] [fcgid:warn] [pid 2733438:tid
139719249733184] [remote 40.77.167.59:21071] mod_fcgid: stderr: Stack
trace:
[Thu Jan 30 04:48:22.256174 2025] [fcgid:warn] [pid 2733438:tid
139719249733184] [remote 40.77.167.59:21071] mod_fcgid: stderr: #0 {main}
[Thu Jan 30 04:48:22.256178 2025] [fcgid:warn] [pid 2733438:tid
139719249733184] [remote 40.77.167.59:21071] mod_fcgid: stderr: thrown
in
/home/[user/journalname]/lib/pkp/classes/user/form/IdentityForm.inc.php
on line 16
I’m not sure if related but the above PHP Fatal error can result in
issues with the IdentifyForm.inc.php. There were also some mod_security
(firewall) warnings but also not sure if this would prevent messages from
being sent:
[Thu Jan 30 18:15:19.830061 2025] [:error] [pid 2082829:tid
139709045012032] [client 52.55.252.139:57022] [client 52.55.252.139]
ModSecurity: Warning. Pattern match “^$” at REQUEST_HEADERS:User-Agent.
[file
“/etc/modsecurity/mod_sec3_CRS/REQUEST-920-PROTOCOL-ENFORCEMENT.conf”]
[line “707”] [id “920330”] [msg “Empty User Agent Header”] [severity
“NOTICE”] [ver “OWASP_CRS/4.7.0-dev”] [tag “application-multi”] [tag
“language-multi”] [tag “platform-multi”] [tag “attack-protocol”] [tag
“paranoia-level/1”] [tag “OWASP_CRS”] [tag “capec/1000/210/272”]
[hostname “thepromptjournal.com”] [uri
“/index.php/prompt/article/view/100”] [unique_id
“Z5wyN9-083913ZI76QrnlgAAdaQ”]
Does this help you point me to possible causes (and potential solutions)? Thank you–
@rcgillis Roger, just realized I hadn’t tagged you here. Does this help you get a clearer sense of what issues we might be facing? Thank you!
Hi @pjaw_tech,
I don’t think any of those log entries shows the problem. The logs can grow quickly, so it’s important to pinpoint the messages that appear at the same time as you encounter the problem. You can do that by noting the exact date/time that you encounter the issue, then checking the logs for that same timestamp. (You’ll probably have to compensate for time zones – the time zone of the server may not be the same as yours.)
I think it’s likely that you’re falling afoul of a mod_security
rule, which thinks due to the content of the discussion between author and editor, that someone is trying to attack the server. If it’s possible to temporarily disable mod_security
, and see if the problem goes away, then I’d recommend that approach. Better still would be to identify the exact rule that’s being triggered, and then adjust or disable just that rule.
Regards,
Alec Smecher
Public Knowledge Project Team