Hi,
I am reaching out to report a bug that we have discovered within our OJS 3.4.0.1, specifically concerning the discussion functionality in the author workflow.
Currently, we have noticed that authors are unable to start a discussion at any stage of the workflow. While the editor can initiate a discussion thread with the author successfully, the author’s attempts to initiate a discussion encounter an issue.
Here’s a breakdown of the problem:
When the editor starts a discussion with the author, the author can effectively reply to the thread and add their message. This functionality is working as expected.
However, when the author attempts to initiate a discussion by clicking on the appropriate button, a message window opens up. Upon pressing the “OK” button to send the message, the window briefly displays a processing circle sign, but no further action occurs. The window remains open, and the message is not sent. Meanwhile, on the editor’s dashboard, a new discussion line appears, but it lacks any accompanying message.
Interestingly, it is not throwing any error in the PHP error log. Thank you for your time and support. We eagerly await your assistance in rectifying this bug.
Can you use your browser’s web development tools to see what the response looks like from the server side when you attempt to start a discussion as Author? What is the HTTP response code (e.g. 200 , 500, etc), and what are the contents (if any) of the response from the server?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
I tried but the browser’s web development tool is not throwing any error. Please see the attached screenshot. On pressing the OK button, a wheel spins briefly next to OK and then disappears.
There is nothing in php error log as well.
Thanks
seisense
I’m not sure what browser you’re using (it’s different than mine) – but look for a “Network” tab, which will capture and inspect network exchanges between the browser and server.
Regards,
Alec Smecher
Public Knowledge Project Team
Hello @asmecher ,
Thanks for pinpointing where exactly to look at…
Below is the screenshot of the network tab and the last two entries of the screenshot appear only when I hit the “OK” button in the add discussion window.
by changing the triple equal to the double equal sign, it has solved two problems:
1- Now the author can start the discussion
2- The editor was not allowed to use the “Notify” option after the change even this function is working fine.
Now the question is do you recommend keeping this change or I should revert this to a triple equal sign? Is this change going to break/harm any other function?
Hmm, this is a curious issue – I wasn’t able to replicate the other type mismatch on my own system, nor this one. I’m using PHP 8.1.21, and I see you are using 8.1 as well. What specific version of PHP are you running? I suspect this is an underlying PHP bug that’s already been fixed, but I’d love to track down the details.
Regards,
Alec Smecher
Public Knowledge Project Team
I have another subdomain where I am still running OJS 3.3.0.14 with the same configuration as above and I never encountered any issues. Before writing this post, I tested all these functions once again (the author can start the discussion and the editor can use the “Notify” function) on this test domain and I found it is working perfectly.
Hope it helps to figure out why PHP behaving strangely on my server.
Regards
seisense
Hmm, the differences between PHP 8.1.20 and 8.1.21 don’t seem relevant – and that’s just a single build gap, which would be surprising if it were the cause. My dev system is very close to yours in other respects too, e.g. the MariaDB version.
I’ve filed and fixed this here…
…however, if anyone is able to investigate the mismatch more deeply, I’d love to know more about it!
Regards,
Alec Smecher
Public Knowledge Project Team
One of us is using mysqlnd, and the other is using mysqli. Checking my phpinfo() output, it looks like I’m using mysqlnd.
One of our systems is emulating prepared statements, while the other is using them natively. There is a PDO option that should be turned off by default for this: PDO::ATTR_EMULATE_PREPARES
One of our systems has “stringify fetches” turned on. There is a PDO option that should be turned off by default for this: PDO::ATTR_STRINGIFY_FETCHES
All the same, this does appear to be something that’s evolving in PHP8.1 (release notes), so the dev team is probably going to have to be careful not to assume sane types coming from the database.
Regards,
Alec Smecher
Public Knowledge Project Team
Heads-up on how to debug this: It’s possible to cause PDO/Laravel/MySQL/PHP to behave in this unusual way by calling (prior to the offending database fetches)…