Failed ajax request or invalid json returned (in galley)

I can not add files in galley, why? there is a message: failed ajax request or invalid JSON returned
error pdf

I also can not open files in the archived at ojs 3.1.01, why so?
error pdf1


Please, check your console log browser to verify error message when loading this panels.

Israel Cefrin
Public Knowledge Project Team

I have a similar problem in Galley and Assign Proofreader. Here the Safari javascript console


We have published the issue without pdf galley, now we want to add the galley. Can it be the source of the problem?
Well, I tried unpublish issue and publish it again. It also shows same error


Adding any changes in journal description, sidebar through custom block manager etc are not working

Dear @asmecher @Vitaliy @ajnyga
After restoring using the old backup, we got some issues;

  1. Could not make any changes to journal description, custom block manager, and might be other features (not yet check them all)
  2. Could not add Galley, assign roles in the editorial process

Is it trouble in the server? Please, any thoughts on this?
We are under the process of publishing the current issue

Hi @kawahyu,

The 500 errors should correspond to further information in your PHP error log.

The problems after restoring from backup are probably related to file permissions in cache.

Alec Smecher
Public Knowledge Project Team

1 Like

It is mine


How do I change the permission?

Well, when I change cache folder and cache/t_compile to 777, Everything back to work normally. However, here How should file permissions be set? - #2 by ctgraham, it is not safe.

The important thing is the find out what user/group does php use when doing write operations. The cache folder should be writable for that user/group. With 777 you are giving write permissions to all users.

1 Like

Thank you. But when uploading pdf galley, I got HTTP error. I have searched about it in this forum, it also relates to file permission but yet a solution found

the same permission requirements apply to the files folder as well. If the folder is not writable for php, the galley file can not be uploaded.

The folders that need to be writable for php are: public, cache and files. The files folder should of course be outside the OJS installation below the web root.

I set them all with 775 but still HTTP error. When cache folder set 775 I could not make any changes to sidebar, journal description etc. It is working on 777 for the change.

It is all getting complicated when the error_log is not accessible. It displayed 500 internal server error as well

No response from subprocess ( (cpanel)): The subprocess reported error number 72,057,594,037,927,935 when it ended. The process dumped a core file.
cpsrvd Server at

I downloaded the file and no current error report. It seems the errors were not recorded. I also found the plugin could not be disabled.

In case of all attempts fail to fix the problems, is a fresh install of ojs with the old database a good idea? What will I lose in the current website if it is the way?

Hi @ajnyga @asmecher
I got this error report. Hope it explains the problem

[Sat Jan 05 16:54:14.112102 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Warning:  file_put_contents(/home/k2542002/public_html/cache/fc-pluginSettings-1-oldgreggthemeplugin.php): failed to open stream: Permission denied in /home/k2542002/public_html/lib/pkp/classes/cache/ on line 90: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:14.110697 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Strict Standards:  Only variables should be assigned by reference in /home/k2542002/public_html/pages/index/ on line 68: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:14.048651 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Strict Standards:  Declaration of CustomBlockPlugin::getEnabled() should be compatible with BlockPlugin::getEnabled($contextId = NULL) in /home/k2542002/public_html/plugins/generic/customBlockManager/ on line 134: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:14.048405 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Strict Standards:  Declaration of CustomBlockPlugin::getBlockContext() should be compatible with BlockPlugin::getBlockContext($contextId = NULL) in /home/k2542002/public_html/plugins/generic/customBlockManager/ on line 134: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:14.023515 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Warning:  file_put_contents(/home/k2542002/public_html/cache/fc-pluginSettings-1-jatsparserplugin.php): failed to open stream: Permission denied in /home/k2542002/public_html/lib/pkp/classes/cache/ on line 90: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:14.001026 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Strict Standards:  Declaration of DRIVERDAO::setOAI() should be compatible with PKPOAIDAO::setOAI($oai) in /home/k2542002/public_html/plugins/generic/driver/ on line 19: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:54:13.986297 2019] [cgi:error] [pid 6925] [client] AH01215: PHP Strict Standards:  Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /home/k2542002/public_html/lib/pkp/plugins/generic/usageEvent/ on line 386: /usr/local/cpanel/cgi-sys/ea-php56
[Sat Jan 05 16:53:50.829606 2019] [cgi:error] [pid 6989] [client] AH01215: PHP Fatal error:  Call to a member function getFileId() on null in /home/k2542002/public_html/lib/pkp/classes/submission/ on line 1065: /usr/local/cpanel/cgi-sys/ea-php56, referer:

Please, any thought for the error logs?
I think I have the same error logs here Add galley http error
Still the permission issue.

Have you asked your service provider about this?

The solution is simply to find out what user/group is php using when writing files and the recursively give that user/group ownership to cache, files and public folders.

1 Like

Thanks @ajnyga
It is resolved by the service provider.
He informed me that a change from php handler to suphp was made.
I did not understand the change made. Maybe you explain it here, so the other who have similar issue could try it

1 Like

this explains it fairly well:

1 Like

Well, pretty clear explanation. When I change to 755, previously work only on 777, it works normally.