Foreign key relationships allows records to be linked together through multiple database tables, for example, linking products to categories. Until now, when a product was to be deleted using the Administration Tool, extra PHP code had to be written within the delete function to also delete entries in other database tables that shared a relationship with the product being deleted.

This is fine for standard installations where the relationships between database tables are known, however when add-ons create new database tables during installation, changes were required in core source code files to also perform database actions on the tables they created.

Now with foreign key relationships, changes to core source code files are no longer required and changes to the related database tables are performed natively on InnoDB databases or automatically through the database class for MyISAM databases. This cleans the codebase considerably and allows one simple query to take care of the whole database. For example:

delete from osc_products where products_id = 1

This one simple query now automatically takes care of deleting the product language definitions, product reviews, category assignments, special prices, shopping cart entries, and any other product table relationships without any additional queries or PHP code necessary.

The following foreign key constraints are supported for MyISAM databases for both ON UPDATE and ON DELETE operations:

• CASCADE, automatically update or delete child records when a parent record is being updated or deleted (eg, delete all product related information when a product is being deleted)
• SET NULL, automatically sets the child record field value to null when a parent record is being updated or deleted (eg, clear the product manufacturer value when a manufacturer is being deleted)
• RESTRICT, prevents a parent record from being updated or deleted if child records depend on it (eg, don’t allow order status levels to be deleted if they are in use by orders)

Add-On developers can take advantage of foreign keys by defining relationships directly in the database schema for InnoDB databases, and by entering relationships in the osc_fk_relationships table for MyISAM databases. Examples of foreign keys defined in the osc_fk_relationships table are:

The osc_fk_relationships table is only used for MyISAM databases and is used by the database class to check on the defined constraints when UPDATE and DELETE queries are being performed.

There are currently 68 foreign key relationships defined that will be introduced in the osCommerce Online Merchant v3.0 Beta 1 release.

The changes are currently available in my development branch at GitHub and will be pushed to the main development branch after further testing and code clean up has been performed. My branch is available at:

http://github.com/haraldpdl/oscommerce/

Documentation on MySQL’s foreign key implementation can be found here:

http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html

All warnings and errors are logged in a text file located in the “work” directory and can be easily viewed in the Administration Tool -> Tools -> Error Log application and summary module.

This is the only Administration Tool application where it’s a good sign when it doesn’t show anything. It gives a nice feeling knowing that any sort of warning or error in the core framework has been checked for, from uninitialized PHP variables to problems with MySQL queries.

Setting the error reporting at such strict levels ensures a high quality of coding standards is kept in the core framework and passes this along to add-ons that are developed and installed.

This makes it easier for developers working on addons where they can see where warnings and errors are occuring in what they have been working on, and motivates them to fix the problems to improve the quality of the finalized work.

A configuration parameter will be introduced in v3.0 Beta 1 to disable the output of PHP warnings and errors on the catalog frontend. This allows the output of warnings and errors to occur under development environments, and to be disabled on production servers.

Both PHP and MySQL highly recommend the use of the newer mysqli extension over the older mysql extension.

It’s been reported that there are still service providers using MySQL v5.0.67. This is actually fine as it is a much newer version than the minimum requirement of v5.0.7.

To clarify the MySQL versioning scheme, the third number in the version string (”7″) is incremented for each new release in the release level.

MySQL v5.0.7 was actually a beta released on the 15th June 2005, and v5.0.67 was released on the 8th August 2008.

There have also been some reports that some service providers are still using PHP v5.1.6. RedHat Enterprise Linux and CentOS are vendors still using PHP v5.1.6. This is unfortunate as it does not meet the minimum PHP v5.2.0 requirement to install and use osCommerce Online Merchant v3.0 Alpha 5.

PHP v5.2.0 was released on the 2nd November 2006.

The first reports of v3.0 Alpha 5 not running properly was due to the use of PHP v5.1.6 which does not contain the json_encode() function introduced in PHP v5.2.0. This function is used heavily in the Administration Tool with the new dynamic table listing and live search features.

A compatibility function exists that might be the saviour to the json_encode() problem for earlier PHP v5.X versions. If you are interested in testing this out, feel free to fork osCommerce on Github and report back of your findings.

Our decision to optimize the v3.0 framework for PHP 5 is based on the end of life support cycle for PHP 4 which ends at the end of this year. The announcement the PHP Group made regarding this coincides with the efforts of the GoPHP5 initiative whom which we are also supporting.

This allows us to concentrate on a PHP 5 optimized framework for future releases in the v3.x release series without the need to spend resources on PHP 4 compatibility past its end of life cycle.

The first PHP 5 optimized commits have already been performed in our development repository which reflects the classes and Object Oriented design of the framework. The new Object Model of PHP 5 allows us to tighten the design of the framework with the use of “object visibility”, and will be the first step in optimizing the framework for PHP 5.

Object visibility is in regard to defining class members and methods into three different visibility levels: public, protected, and private, which reflect how they can be accessed from outside the class, within the class, and within its inherited children.

The three levels function as:

public – this element can be accessed from inside and outside the class object
protected – this element can be accessed from inside the class object and its inherited children
private – this element can only be accessed from inside the class object

We’ll take a look at a shortened version of the session class to describe how each three visibility levels work.

class osC_Session {
protected $_id = null;
protected $_name = 'osCsid';

protected function _setCookieParameters($lifetime = 0, $path = null, $domain = null, $secure = false, $httponly = false) {
return session_set_cookie_params($lifetime, $path, $domain, $secure, $httponly);
}
}
?>

The class members $_id and $_name are both protected and allow only to be accessed from within the class and its inherited children. This disallows accessing these members from outside the class as shown in the following example:

$osC_Session = new osC_Session();

echo $osC_Session->_id; // not allowed
$osC_Session->_name = 'test'; // not allowed
?>

To allow access to these members from outside the class they must be defined with the public visibility level. As we don’t allow this as part of our coding standards, get and set methods are defined in the class that allow public access to the class members, as shown in the following example:

$osC_Session = new osC_Session();

echo $osC_Session->getID(); // allowed
$osC_Session->setName('test'); // allowed
?>

Accessing the getID() and setName() class methods from outside the class object is allowed as these have been defined with the public visibility level.

On the other hand, the _setCookieParameters() class method is defined with a protected visibility level and cannot be accessed from outside the class object. The _setCookieParameters() class method can therefore only be accessed from within the class and its inherited children, as is being done in the class constructor.

The session implementation in v3.0 (Alpha 5) has been impoved to allow modules to be loaded that define how the storage of the session data is accessed. An example session module is the database module that stores the session data in the database. Each session module is an extension to the osC_Session class and therefore inherits its class members and methods.

This allows the database session module, named osC_Session_database, to access the public and protected class members and methods from the main osC_Session class.

If there were class members and methods defined in the osC_Session class with the private visibility level, its inherited children such as the osC_Session_database class would not be allowed to access it.

The default behaviour in PHP 4 is to allow full public access to all class members and methods. By using the visibility levels PHP 5 provides, it is possible to disallow public access to class members and methods to keep certain functionality for internal use by the framework only.

Further information regarding object visibility levels can be read at the PHP Manual.

As each class is being updated in the framework, phpDocumentation is also being written to provide a developers API guide with the v3.0 release, that describes each class member and method. This documentation will be completed during v3.0 Alpha 5 and v3.0 Alpha 6.

Although 40410 fixed a posix related compilation error, usage of the PHP function posix_getgrgid() in PHP 5.2.1 returns the following fatal error:

Fatal error: Out of memory (allocated 2097152) (tried to allocate -1 bytes) in /tmp/test.php

This was reported to Anthony Dovgal, who took care of 40410, and confirmed that this problem was fixed in 5.2.2-dev (php5.2-200702281330).

I came across this problem today while working on the Administration Tool -> Tools -> File Manager section, which uses the posix_getgrgid() function to display the group owner name of the files and directories. As Mac OS X is based on BSD, it also affected my development environment.

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.

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.

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