osCommerce

PHP 5.2.0 was recently released which “includes a large number of new features, bug fixes and security enhancements” to the PHP 5.x series. The PHP Group also published an upgrade guide for existing PHP 5 users that documents the (incompatibility) changes the new release brings.

osCommerce 2.2 Milestone 2 Update 060817 works fine with PHP 5.2.0 (with register_globals and register_long_arrays enabled).

There is however one change that 5.2.0 brings in that causes osCommerce 3.0 Alpha 3 to produce a PHP FATAL error in the sessions implementation, specifically when the session data is stored in the database (by default for osCommerce 3.0).

This is due to a change in session_set_save_handler() where the “write” and “close” handlers are called after objects have been destructed.

As the sessions implementation in osCommerce 3.0 is done in a class/object, writing session data and closing the session are no longer possible as the registered object would be destructed and no longer exist to perform those duties.

The proper solution here is to use session_write_close() in the destructor of the osC_Session class:

class osC_Session {
...

function __destruct() {
session_write_close();
}
}

As __destruct() is a PHP 5 feature only, an alternative solution is needed for PHP 4 compatibility (the minimum requirement for osCommerce 3.0 will be PHP 4.1), and that is to register session_write_close() as a shutdown function:

session_set_save_handler(array(&$this, '_open'),
array(&$this, '_close'),
array(&$this, '_read'),
array(&$this, '_write'),
array(&$this, '_destroy'),
array(&$this, '_gc'));

register_shutdown_function('session_write_close');

This has already been reported at our new Issue Tracker and has been fixed at r1107.

I just experienced another nasty PHP4 / PHP5 compatibility issue that plagued the logging features of the support site administration tool (which is planned to be introduced in the 3.0 Alpha 4 release).

The implementation uses the strrpos() function to grab the end of a string from a string searched starting point. The opposite function is strpos() that searches from the start of the string instead from the end.

The string to search for, the needle, can be a character or a string for the normal strpos() function in both PHP 4 and PHP 5.

There is however a difference with the strrpos() function where PHP 4 accepts the needle as a character only, and can first be a string from PHP 5 onwards.

This took some time to debug where my local server is running on PHP 5 with the logging features working fine, and the support site running PHP 4 where the issue was first evident.

There is a warning about this on the documentation page which I overlooked during the implementation phase. Such incompatibility warnings should be marked with the infamous <blink> tag so they stand out better

The positive side to this is the valuable user comments on the php documentation pages where numerous functions are provided to workaround the problem.

Workaround functions are obviously not elegant solutions to use, and will look at improving the logic further for the 3.0 Alpha 4 release.

It looks like we have to use another compatibility function due to inconsistencies between PHP versions.

For PHP versions below 4.3.5, defined() returns an integer (1 or 0), whereas from 4.3.5 onwards it returns a boolean (true or false).

This makes it impossible for us to use the following:

if (defined('CONSTANT') === true) {
...
}

A note has been added to the PHP documentation page to warn others of this inconsistency.

Relevant bug report:

http://bugs.php.net/bug.php?id=27443