OJS 2.4.8 and PHP 7.2 Compatibility

Dilan_Rostam · November 26, 2018, 3:33pm

Thank you for digging this up. I have a System Admin but he is not a developer. He is now trying to install support for PHP 5.6 for Debian 9.6. If this works then we might be able to wait till you are ready with updating legacy OJS and OCS. If he fails then we are in square one.

The Git is Plask is a 3rd party module and not a Plesk function. Yes our Server has SSH access but that process is too technical for me.

Dilan_Rostam · November 26, 2018, 7:05pm

Now we managed to install PHP 5.6 on Debian 9 and that solved issues. I hope you guys manage to keep alive these legacy applications OCS and OJS 2.4.8 by addressing the PHP 7 compatibility issues.

For anyone might have the same issue, we followed this solution to make the OCS and OJS 2.4.8 work on Debian 9.6

Thank you sparing time to answer my questions…

Dilan_Rostam · December 5, 2018, 9:40pm

This issue has become a rabbit hole for us. Now we can not fix the SMTP. We have done every possible solution and we keep getting an error log as

[Wed Dec 05 06:53:17.482519 2018] [cgi:error] [pid 1876] [client 103.41.47.16:55628] AH01215: OJS SMTPMailer: Did not receive expected 220: /var/www/cgi-bin/cgi_wrapper/cgi_wrapper, referer: http://aro.koyauniversity.org/login/lostPassword

Please check whether we can do anything to solve this issue.

ctgraham · December 6, 2018, 1:11pm

Since this relates more to the change of server and the SMTP connection than it does to PHP 7.2 compatibility, it may be better to start a new thread for this.

That said, the message you are receiving comes immediately after a (presumably) successful network connection from your server to the SMTP server:

github.com

pkp/pkp-lib/blob/ad17dd567068aa7b50f6931edda5617ae6558f8f/classes/mail/SMTPMailer.inc.php#L70


	 * @param $subject string
	 * @param $body string
	 * @param $headers string
	 */
	function mail(&$mail, $recipients, $subject, $body, $headers = '') {
		// Establish connection
		if (!$this->connect())
			return false;

		if (!$this->receive('220'))
			return $this->disconnect('Did not receive expected 220');

		// Send HELO/EHLO command
		$serverHost = Request::getServerHost(null, false);
		if (!$this->send($this->auth ? 'EHLO' : 'HELO', $serverHost))
			return $this->disconnect('Could not send HELO/HELO');

		if (!$this->receive('250'))
			return $this->disconnect('Did not receive expected 250 (1)');

		if ($this->auth) {

In this case, it appears the SMTP server is not talking SMTP.

Note that if your new server is configured to support the PHP mail() function (most are out-of-the-box) and if you are using an email domain which trusts your server (common in institutional settings), it is probably easier to just turn off SMTP and use the native PHP mail().

If you need to use SMTP, please provide additional details on your SMTP server and how you have configured SMTP within OJS in a new thread and we can try to help to troubleshoot.

voidead · December 6, 2018, 5:34pm

We are using google gsuite mail smtp within the ojs config file.

See below setting in config.inc.php

[email]

; Use SMTP for sending mail instead of mail()
smtp = On

; SMTP server settings
smtp_server = “smtp-relay.gmail.com:465”

Also same setting is working with the other website with ojs 3.x

ctgraham · December 6, 2018, 8:43pm

Can you (or your system administrator) test to confirm that you can access port 465 of smtp-relay.gmail.com from this server? (Or alternately, is the working website on the same virtual or physical server?)

Dilan_Rostam · December 7, 2018, 9:01am

Yes, I can confirm that our OJS 3 website on the same server is working properly with same setting on port 465.

Also the server support PHP Mail

Please note that we had issue with OJS 2.4.8 on this new server Debian 9.6 which supports only php 7, but we extended and installed PHP 5.6 based on instruction above. We got the site working but it seems that SMTP has issue.

ctgraham · December 7, 2018, 1:52pm

If the server supports the PHP mail() function, I would try using this instead by turning smtp to “Off” in config.inc.php.

OJS2 uses a custom SMTP mailing class whereas OJS3 uses the PHPMailer library. As a result, the settings required in config.inc.php for each are different, even when the same servers are involved. PHPMailer will certainly also have additional features beyond the OJS2 custom class.

If you need to use SMTP with OJS2, I think the way to discover the nature of the actual error would be to temporarily modify this function:

github.com

pkp/pkp-lib/blob/ad17dd567068aa7b50f6931edda5617ae6558f8f/classes/mail/SMTPMailer.inc.php#L211-L229


	/**
	 * Receive a response and return the data payload.
	 * @param $expected string/array expected response code
	 * @param $data string buffer
	 * @return boolean
	 */
	function receiveData($expected, &$data) {
		do {
			$line = @fgets($this->socket);
		} while($line !== false && substr($line, 3, 1) != ' ');

		if ($line !== false) {
			$response = substr($line, 0, 3);
			$data = substr($line, 4);
			if ((is_array($expected) && in_array($response, $expected)) || ($response === $expected))
				return true;
		}
		return false;
	}

You would want to remove the error suppression (@ symbol prefixing fgets) on line 219, and add an else condition to the if on line 225 to dump $response to the error log. You could then test a message and view the error log to see what the server is actually responding with when OJS is expecting an SMTP 220.

MacMike · December 17, 2018, 7:53pm

Any chance we can get a patch kit for the differences between the latest Current Stable Release OJS 2.4.8-3 (.tar.gz) and the current stable GitHub release since PHP 5.6 is going EOL at the end of the month?

ctgraham · December 17, 2018, 8:23pm

Patching should be done via Git for those who are technically inclined. I think we are finally moving away from distributing patchfiles, and I strongly support that move.

For general users, we are trying to offer more rapid official releases. This has obviously benefited 3.x users most, but I do think a 2.4.8-4 or 2.4.9 in the near future is likely. I don’t see the PHP 5.6 EOL as a hard deadline for this, but I do think it is a good motivator.