Problem assigning participants

I’m using OJS 3.1 and when I try to assign participants, an editor for example, the systems does not display the list of participants: it only display a “loading” message.
Here is an image. Loading%20participants
What can I do? Thanks,


Do you have any php error log available to post here?

I tried now on my test installation and it works normally.
Is your installation fresh or upgrade? What is version of php that you use?
Did you assign section editor for article in that section?

Hi, Vedran, thank you for your help.

My answers:

I do not have any php error log.

My installation is fresh (3.1.0)

The php version is 5.5.37

I cannot assign section editors or any other user (editors and reviewers), this is just the problem. When I click the assign button the system starts “loading” but no list is displayed ever.

In the corresponding window I do can select an email message.

The above is odd, because if i go to Users the hole list is displayed.

Thanks again for your help.



Hi @GBuendia,

OJS 3.1 requires at least PHP 5.6.

Alec Smecher
Public Knowledge Project Team

Please inform me do you have versio 3.1.0 or 3.1.0-1.
If you have 3.1.0please upgrade it to 3.1.0-1


Thank you!!! I will update both versions, thanks


I have the same problem. My installation is an upgrade, but I have PHP version of 7.0.27 and OJS version Is there anything I can do to solve this?

Hi @p_urbanczyk

Do you see any error in your server PHP error log file? – not warnings and strict standard messages, but only errors are important.

Also, do you use release package or git?


Hi @bozana

Thank you for your reply.
It seems that there’s no error log file configured on my server.
I used release package. I made an upgrade on my local server and then moved the files to the online hosting and import the database via phpmyadmin. Probably, that caused this, because on my local server there’s no problem with assigning participants. Is there any way to sort this out?


You should not expose you php-info file publicly – please remove it (and the link above)…

Maybe then to first set up the log files correctly – they are useful and needed however – then to see further…


I think it has something to do with this entry:
[Tue Jul 10 16:06:41 2018] [error] [client] ModSecurity: Access denied with code 403 (phase 2). Pattern match "\\bselect\\b.{0,40}\\buser\\b" at REQUEST_FILENAME. [file "/usr/local/apache2/conf/modsecurity/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "67"] [id "959514"] [rev "2.1.1"] [msg "Blind SQL Injection Attack"] [data "select/user"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname ""] [uri "/index.php/zfn/$$$call$$$/grid/users/user-select/user-select-grid/fetch-grid"] [unique_id "W0S9cQoAUgEAAH9I2dEAAABR"]

EDIT: Moreover, I can assign participants, when I turn off the option that my hosting provider calls “Firewall” (or increased security option). Is there any way to solve this out with this so-called “Firewall” still being turned on?

Hi @p_urbanczyk

I am afraid I do not know further – it seems to be some configuration/set up on your server…
Maybe @asmecher would have an idea/a hint?

EDIT: also maybe you can search this forum after “mod security” to see if some other uses have a similar problem and if there is a solution you could try…


After a phone call with hosting provider support I can confirm that this “Firewall” is just mod_security added to the server. Unfortunately, since its a shared hosting, I cannot manually change any rules within it.

According to the hint given by @ajnyga in this thread it may be caused by a string containing the words SELECT and USER close to each other. I searched the database and I can confirm that none of the editors (and users in general) have these words combined in their database entries, nor these two words occur in any string related to this action (4 matches in email_templates_default_data, but those emails concern review requests and 2 matches in submissions, but those are completely unrelated bibliographies of the articles). So, I am pretty sure (as @ajnyga suggests two posts below in the linked thread) that mod_security is triggered by the url “/index.php/[xxx]/$$$call$$$/grid/users/user-select/user-select-grid/fetch-grid” itself.

I have the same case you have. until now, i do not have idea how to solve it. anyone can help us please?