I have searched the forum for postings similar to this and while I found responses related to reverting the PHP from 8.2 to 8.0, this solution did not make a difference. Other solutions and messages did not apply to this situation. My apologies for missing anything else!
Our host is moving its VPS cloud to a new server, and will be moving our OJS installation with it. It has been working well on the current server, but the test (destination) server seems to be rejecting the OJS – or the other way: the OJS is rejecting the test server…I cannot tell. I did notice that the database servers are different: 10.5.29-MariaDB (current), 11.4.10-MariaDB (test/destination). Could this also be a culprit? I have asked them to set the PHP version 8.0.30 and they did, but the error is still showing.
Basically, the test server has caused the OJS submission dashboard to show no activity (unassigned, all active, archive…nothing showing there) whereas there are many on the current OJS installation. User management is impossible because while the users are showing, editing users generates the “Failed Ajax request or invalid JSON returned” error message. Journal editing is also dysfunctional: while the journals are showing under hosted journals, any attempt to edit any of the journals returns this same message. The statistics are also showing but an attempt to creeate PHP reports generates an “Error processing page: Failed to fetch page: Operation timed out after 20134 milliseconds with 700459 bytes received” message.
I cannot look into the error log, as I have no access to the test server functionalities like cPanel there. There are no issues on the current site, so no relevant error log lines there! What other issues should I look at? I am holding off on upgrading to OJS 3.5 as it is not an LTS, and as you know upgrading from 3.3 to 3.4 or later is not a matter of a simple click on a link. I have posted on that a couple of years ago and received helpful tips about moving the home directory, database, and some critical configurations, but with a short migration deadline, that is not a priority. Thank you in advance for any suggestions you may offer in this matter.
You’ll need to get access to the PHP error logs to debug this – otherwise you’re going to have a very hard time debugging. This will apply to any trouble you encounter later, so it’s worth resolving now. Simply put, if you can’t access your PHP error logs, it’s not a good place to host PHP applications.
Thanks,
Alec Smecher
Public Knowledge Project Team
They have other servers that do support PHP 8, and the current server this has been working well for the 5 years we were with them (TMDHosting). I have also suggested them to look at the error logs since I do not have access to the cPanel of the testing server, so they need to figure this out. Regards, Arjun
Hi Alec, the hosts suggested that I add a line with the new IP address and the domain name to my local host file, which requires admin-level access to my computer. So, I did just that and it appears that the OJS is functional. So, apparently, this is not a database or PHP-specific issue, but as OJS admin, I do not see a way to make changes to the system information without going into the cPanel of the new server (and I do not have that access yet). I would like our journal editors to be able to test things out in the OJS in the new server to make sure everything is as they should be. Any recommendations? Thank you in advance! – Arjun
All that “modifying your local host file” (etc/hosts?) does is it lets your system to bypass the DNS requests, because the IP address that corresponds to the domain name is taken from the local hosts file. So your issue appears to be related to the DNS and not the OJS.
For making the “remote” (not local) test installation after unrolling the OJS from the backup on a new server, one basically has two options (that I know of). The first one is to point some A/AAAA DNS record of a test domain name to the new IP address, change the base_url in config.inc.php of OJS to account for the test domain name, issue the TLS certificates for the new test domain name, and use the backup OJS accessible under the test domain name. The second one is to temporarily modify the hosts file, relating the IP of the test server to the domain name of the main OJS installation. Then you are able to access the test OJS as usual, and you don’t have to modify the DNS records and config.inc.php settings. You can even use the TLS certificates from the main server on the test server.
What I’m saying is the latter approach is also neat for testing, if everyone on the test team modifies their hosts file. When you are ready to make the test installation your primary one, you’ll only need to alter the A/AAAA DNS records to point them to new IPs.
I was pointed to a preview.org site where I enter a domain name and IP address and it generates a URL but it does not handle PHPs well (or at all). I wanted our journal editors to test their journals on OJS to make sure all is set before I contact the IT department to point the A record to the new nameserver. Editing the hosts file may present challenges to those who do not know how to enter the admin account on their own computers (because the employers’ computers are usually blocked by IT policy). So, is there a third-party preview tool that does handle PHP? I would also like to explore if there is any OJS inspection tool that diagnoses the OJS installation and spot issues (without having to go through error logs),
I’m afraid that this advice isn’t making any sense to me; the preview.org site you were directed to doesn’t have any relevance to OJS, and it shouldn’t be necessary to edit the hosts file unless you’re trying to locally emulate a nameserver change. I’d suggest staking a step back from what you’re working on to make sure you’ve got a handle on the problem; it’s easy for small changes to snowball into a large mess.
For DNS and domain administration issues, you might find stackoverflow.com to be a better resource; that configuration needs to be done outside of OJS, and OJS and PHP don’t particularly care what domain you use as long as the request comes through.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks, Alec, I totally agree. Adding a line to my hosts file (as an administrator) did help me bypass the DNS process at our university, but that is just temporary, and it helps me test the OJS in the destination server. I created a checklist to test how the system handles OJS operations and thus far it is working. Are you aware of a checklist to use when inspecting an OJS installation? I tried to look for a diagnostic plugin to spot any OJS issues, but no luck, so the checklist is the next best thing. Right now, the PHP 8.0.30 is working, MariaDB11.4.10 is not causing any issues, so this may just work out. Regards, – Arjun
For testing, you can use the upgrade checklist. It covers some commonplace usage. In addition, follow your own editorial process (from submission to publication and post-publication activities, such as XML exports) to see if everything works.
Thank you, Vladimir @voffch ! This is very helpful. I have had some of this down on my improvised checklist but not nearly as organized as this list. We are also looking at an impending upgrade from 3.3 LTS to 3.5 LTS, which–as you know–is not a simple act of a click of a button like you see with Firefox browsers. All my best, Arjun @asabhar