We discovered the problem last Saturday. No changes were made on the server side, only the regular work of editors and managers in different journals.
Did anyone changed something in database such as collation or collation of connection with server? You can check that by comparing charsert/collation of connection with server and collation of tables in database. if you use phpmyadmin you can check that easily.
No, we did not make any changes from our side at the database level.
Many thanks to vvucic, here are some screenshots from browser error console:
Also, I want to note that after login, even the header with the buttons for profile editing and logout is not loaded:
Hi @rkhalikov,
Are PHP error messages directed to the browser in your php.ini? If so, make sure they’re directed to the log instead. There’s a JSON parse message that suggests something extra is corrupting the message, and this is the most common cause.
If that doesn’t appear to be the problem, I’d suggest using a web developer toolset in your browser (most browsers now include them) to inspect the JSON response that’s causing that error message in your browser console.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi, Alec!
Here are our php.ini settings concerning errors logging:
error_reporting = E_ALL
display_errors = On
log_errors = On
html_errors = On
OK, I tried Chrome Developer tools, here is an example just after login:
Hi @rkhalikov,
I would suggest turning display_errors to Off. This is recommended for production use and that alone may resolve your issue.
Regards,
Alec Smecher
Public Knowledge Project Team
OK, done. It was a temporary setting during migration to PHP 7. It does not affect our issue unfortunately…
Hi @rkhalikov,
OK, let’s move on to inspecting the JSON response that’s causing the parse error. Use the “Network” tab to list transactions with the web server, and look at the one that should be responding with a list of submissions. This is the one that should be returning valid JSON, but appears to have something else jammed into it.
Regards,
Alec Smecher
Public Knowledge Project Team
Hm, there are a lot of info in the network tab:
Hi @rkhalikov,
You can cut down on a lot of that traffic by turning on the content delivery network (CDN) for Javascript. See config.inc.php. [Edit: this should be the minification setting, not CDN. -AS]
You’re looking for a request that has _submissions in the URL.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks, CDN enabled now.
I have no _submissions in URLs at all 
There are a lot of submissions as Initiator and few submissions in the Name:
Hi @rkhalikov,
Ah, I see you’re using OJS 3.0.2; the _submissions endpoint was introduced in OJS 3.1. For OJS 3.0.2, look at the myQueue request.
Regards,
Alec Smecher
Public Knowledge Project Team
Yes, we are still on 3.0.2. OK, I see only one the myQueue request - https://…/submissions/myQueue?_=1519932735846
Hi @rkhalikov,
That’s the one. Have a look at the server response and see if you can spot anything unusual (i.e. that’s not valid JSON).
Regards,
Alec Smecher
Public Knowledge Project Team
I don’t know how valid JSON response looks like. Here is what I see:
Hi @rkhalikov,
Your OJS has been exploited and some spam links have been injected, I’m afraid. Is your files_dir somewhere web-accessible?
Regards,
Alec Smecher
Public Knowledge Project Team
As far as I know files_dir is accessible only after login to OJS. What can we do in this situation?
Hi @rkhalikov,
Not if you’ve put it on your server where it can be accessed without going through OJS; see ojs/README at ojs-3_1_0-1 · pkp/ojs · GitHub for details.
Regards,
Alec Smecher
Public Knowledge Project Team
If I try to access https://…/files/ without OJS login I get 404.