A journal has custom domain, it fails to create new submission being stuck in the upload file step. Please see attachment.
Steps I took leading up to the issue:
log in this custom journal, then go to Dashboard click on Submission, click on New Submission top right, then follow onscreen instruction to check all required boxes, then click on Save and Continue that will take you to Upload Submission
Click Add File top right and browse for a file on your computer. The upload will get stuck as seen in attached screenshot.
What I tried to resolve the issue:
Searching the web, tried uploading different files and types, no message found in error logs.
Application Version - e.g., OJS 3.1.2:
OJS 3.3.0-8
Additional information, such as screenshots and error log messages if applicable:
1 attachment.
Please help us out and thank you so much in advance.
I have full access to the server, this error does not seem to show in the logs but I am attaching here anyways.
I can always reproduce the issue if you want to see it in a remote session, I will be happy to show.
Thank you so much for your time!
Best.
Dung.
log 1 (freshly generated just before the error):
[Tue Jan 04 09:52:53.744346 2022] [php7:notice] [pid 39572] [client 136.159.96.252:54953] ojs2: 404 Not Found, referer: https://cdm.ucalgary.ca/cdm/index.php/cdm/user/viewPublicProfile/17465
[Tue Jan 04 09:59:05.320813 2022] [php7:notice] [pid 39798] [client 136.159.96.252:57074] ojs2: 404 Not Found
[Tue Jan 04 10:01:35.039624 2022] [php7:notice] [pid 40006] [client 136.159.96.251:56646] ojs2: 404 Not Found
[Tue Jan 04 10:09:24.632205 2022] [php7:notice] [pid 40624] [client 136.159.96.253:57724] ojs2: 404 Not Found
log 2 (freshly generated just before the error):
[Tue Jan 04 09:28:02.950744 2022] [php7:notice] [pid 37916] [client 136.159.96.250:63961] ojs2: 404 Not Found, referer: https://journalhosting.ucalgary.ca/index.php/sppp/article/download/42470/30362/0’A=0
[Tue Jan 04 09:28:15.405010 2022] [php7:notice] [pid 37921] [client 136.159.96.251:43400] ojs2: 404 Not Found
[Tue Jan 04 09:29:43.788356 2022] [php7:error] [pid 37991] [client 136.159.96.252:44009] script ‘/var/www/html/ojs/xmlrpc.php’ not found or unable to stat
[Tue Jan 04 09:33:02.910172 2022] [php7:notice] [pid 38245] [client 136.159.96.253:4224] ojs2: 404 Not Found
[Tue Jan 04 09:36:27.852490 2022] [php7:notice] [pid 38442] [client 136.159.96.251:60661] ojs2: 404 Not Found
[Tue Jan 04 09:36:56.758504 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Illegal string offset ‘en_US’ in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.758533 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Cannot assign an empty string to a string offset in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.758543 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Illegal string offset ‘fr_CA’ in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.758546 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Cannot assign an empty string to a string offset in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.779461 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Illegal string offset ‘en_US’ in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.779490 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Cannot assign an empty string to a string offset in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.779500 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Illegal string offset ‘fr_CA’ in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:36:56.779504 2022] [php7:warn] [pid 38439] [client 136.159.96.250:58584] PHP Warning: Cannot assign an empty string to a string offset in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: https://scholar.google.com/
[Tue Jan 04 09:37:30.893895 2022] [autoindex:error] [pid 38507] [client 136.159.96.251:39704] AH01276: Cannot serve directory /var/www/html/ojs/public/journals/41/: No matching DirectoryIndex (index.php,index.html,index.php) found, and server-generated directory index forbidden by Options directive, referer: https://journalhosting.ucalgary.ca/index.php/cjeap/article/view/58375
[Tue Jan 04 09:42:26.572398 2022] [php7:notice] [pid 38832] [client 136.159.96.253:29288] ojs2: 404 Not Found
[Tue Jan 04 09:48:08.921398 2022] [php7:notice] [pid 38844] [client 136.159.96.251:61174] ojs2: 404 Not Found, referer: https://scholar.google.com/
[Tue Jan 04 09:50:33.123136 2022] [php7:error] [pid 39177] [client 136.159.96.251:64485] script ‘/var/www/html/ojs/wp-login.php’ not found or unable to stat
[Tue Jan 04 09:50:33.372194 2022] [php7:notice] [pid 39177] [client 136.159.96.251:64485] ojs2: 404 Not Found
[Tue Jan 04 09:53:54.804368 2022] [php7:notice] [pid 39662] [client 136.159.96.251:32064] ojs2: 404 Not Found
[Tue Jan 04 09:54:17.126254 2022] [php7:notice] [pid 39715] [client 136.159.96.252:39041] ojs2: 404 Not Found
[Tue Jan 04 09:57:32.342520 2022] [php7:notice] [pid 39929] [client 136.159.96.253:23884] ojs2: 404 Not Found, referer: https://journalhosting.ucalgary.ca/
[Tue Jan 04 10:03:05.635118 2022] [php7:notice] [pid 40293] [client 136.159.96.253:64032] ojs2: 404 Not Found
[Tue Jan 04 10:06:48.813683 2022] [php7:notice] [pid 39803] [client 136.159.96.253:29502] ojs2: 404 Not Found
[Tue Jan 04 10:13:42.564495 2022] [php7:notice] [pid 40690] [client 136.159.96.250:47602] ojs2: 404 Not Found
[Tue Jan 04 10:14:15.299178 2022] [php7:warn] [pid 40938] [client 136.159.96.253:38345] PHP Warning: ini_set(): A session is active. You cannot change the session module’s ini settings at this time in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/session/SessionManager.inc.php on line 69
[Tue Jan 04 10:14:15.952372 2022] [php7:warn] [pid 40942] [client 136.159.96.253:47313] PHP Warning: ini_set(): A session is active. You cannot change the session module’s ini settings at this time in /var/www/html/ojs-3.3.0-8/lib/pkp/classes/session/SessionManager.inc.php on line 69
Thanks for sharing. Not entirely sure what is going on here, but I will pass it along for some of our other team members to have a look at when they are available.
I have spent quite a bit of time (with other colleagues) we found out for some reason that this problem will only happen on a *custom domain names for example:
We are hosting multiple journals/instances as opposed to single instance/journal. So we have a **main domain name which has many journals such as:
https->://journalhosting.ucalgary.ca/
then we also have other *custom domain names for some other journals (each domain name is for one journal only) because there is a need for that such as:
https->://cjc-rcc.ucalgary.ca/
https->://cdm.ucalgary.ca/
… and a few more (I will attach its configuration to show you) …
Again for some reason this UPLOAD problem is only happened on *custom domain name such as (https->://cdm.ucalgary.ca/submission/wizard/2?submissionId=74371#step-2). So I am wondering if it is possible for the configuration of *custom domain names to interrupt the upload process (or interrupt the javascript if any)?
In a sandbox environment where we do not have *custom domain names this problem does not happen.
Here are my multi ojs instance related configurations:
The file PKPManageFileApiHandler.inc.php is probably not the culprit. This file is invoked when uploading a file during the submission workflow (ie - Review Files, Revisions, Files for Copyediting, etc). It is not invoked during step 2 of the submission wizard in 3.3.0-8.
I suspect the problem is related to domain configuration and the base_url. Unfortunately, I’m no good at this, but probably someone in our community is running in such a configuration and will have some ideas.
In the meantime, can you tell us what the HTTP response is? In the first screenshot, you showed the Console log. There’s a Network tab there and inside of that there should be a XHR tab. When you upload a file, you should see a record of the XHR request(s), and you can inspect the Request and Response. If you can show us both the Request and the Response we might be able to deduce something from that.
Hmm, I can’t tell what’s going on, unfortunately. I did notice that there seems to be a 302 redirect in one of the screenshots.
The first files request has a 302 status and then a 200 status. I wonder if this is causing the problem. Can you look at both requests to determine the Request URL? (This was the small .txt file that worked.)
My guess is that maybe the API call leads to a 302 redirect, but that on large files this is causing it to fail for some reason. But I’m definitely out on a limb here. How large is the .pdf file?
It never worked for small .txt or any files on a custom domain configuration.
The difference between a successful upload and unsuccessful upload is that the unsuccessful upload will result in Chrome’s debug network console status “stalled” as I pointed out in this thread previously.
The .pdf had 522 kb that will upload successfully on my local development Win server with the same OJS version.
It’s looking likely to be something like this. The requests look correct (they go to the correct URL and have the right payload). I’m still curious about that pair of requests with 302 / 200.
But it’s looking like a server config thing and I’m afraid I can’t be much help with that.
Hi everyone (and @Dung nice to chat with you again),
Just coming in to offer my two cents here. If there’s a XHR request occurring and a 302 redirect happening, you may be moving cross domain, and in those requests are not allowed unless you specifically allow them via a CORS policy. You may not even be seeing the errors here because (if like us) they may be getting logged in an apache log file for a different domain, or maybe the browser console is logging them instead. I see a lot of web developer console screenshots above but I don’t see anything shared from the javascript console.
This is a bit fresh in my mind because we host a journal that is the only journal in an installation using a custom URL. To prevent cross-journal access on the custom url, there are Apache mod_rewrite rules that send requests for other journals to the normal base URL. I had originally forgotten a case where requests to API calls (which do not go through index.php) were not being allowed through and those were being redirected to the regular installation domain and thus being blocked due to the default CORS policy not allowing them.
Should I allow custom domains in CORS policy, safe? Our University has proxy server in front of our OJS server, on which one do I config to allow CORS policy (my OJS server or Proxy server), notice that I do not have access to University proxy server.
