Archive

Archive for the ‘osCommerce’ Category

Optimizing for PHP 5; Object Visibility

July 20th, 2007 Harald Ponce de Leon Comments off

With our recent announcement of optimizing the osCommerce Online Merchant v3.0 release for PHP 5, I will begin blogging about the changes performed here for the v3.0 Alpha 5 and v3.0 Alpha 6 releases to serve as a guide for our community developers. This should help in understanding how the v3.0 framework is designed and how add-ons can take advantage of the optimized framework.

gophp5-100x33.pngOur 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';

public function __construct($name = null) {
$this->setName($name);
$this->_setCookieParameters(SERVICE_SESSION_EXPIRATION_TIME);
}

public function getID() {
return $this->_id;
}

public function getName() {
return $this->_name;
}

public function setName($name) {
session_name($name);

$this->_name = session_name();
}

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.

Categories: PHP, osCommerce Tags:

New Forum Server

May 14th, 2007 Harald Ponce de Leon Comments off

I’m glad to report that the forum has successfully migrated to a new server. The move started last week on Friday which left the forum in a read-only state that led into the weekend. This was required to keep the database consistent while the DNS changes were taking place, and to make sure the new server could handle the load properly incase it had to go back to the old server.

The read-only state was removed on Saturday where logins, new registrations, and postings were being accepted again, and has so far been running fine.

Categories: osCommerce Tags:

History Lesson: register_globals In osCommerce 2.2

April 25th, 2007 Harald Ponce de Leon Comments off

Although our development priorities are with finalizing the 3.0 release, a final 2.2 release will also be made prior or simultaneously with the 3.0 release. This will move the 2.2 Milestone 2 release into a final 2.2 release with a small number of known bug fixes, and will close the 2.x release line.

No major features will be introduced into 2.2 as any framework enhancements would break compatibility with add-on contribution packages, and any feature missing is likely to be found with over 4,000 add-ons currently available.

One core framework change that will be introduced with 2.2 is a compatibility layer for servers with register_globals disabled. Currently 2.2 Milestone 2 demands that register_globals be enabled otherwise it refuses to continue working.

The register_globals requirement has always existed since the beginning with The Exchange Project Preview Release 1.0 (March 2000) as at this time PHP 3 was used commonly in conjunction with PHPlib (for session management) and the release of PHP 4.0 was being anticipated with the new Zend engine and native session management support.

Trivia: The Exchange Project Preview Release 1.0 only supported PHP 4 at the time due to the native PHP session management functionality it introduced. It was not until June 2000 that PHP 3 support was added with using PHPlib for its session management functionality, with the release of an “extra pack” for The Exchange Project Preview Release 1.1. Support for PHP 3 at the core level was introduced with The Exchange Project Preview Release 2.0 in December 2000.

The programming standards since The Exchange Project 1.0 to osCommerce 2.2 Milestone 2 have used proper variable scope usage for the $HTTP_GET_VARS ($_GET) and $HTTP_POST_VARS ($_POST) variables. As security and register_globals were non-issues back in the day, the main reason for using correct variable scope usage here were to inform developers which scope the variables were being accessed from. The only variables not used in its correct scope were the session variables which were accessed at the global scope (hello $HTTP_STATE_VARS), and was programmed in mind with register_globals being enabled (which it was by default until PHP 4.2.0 (April 2002)).

Although register_globals needed to be enabled, it was not until June 2002 that it was forced upon in osCommerce 2.2 Milestone 1 (February 2003) with an evil exit() message if it was disabled, as a means to reduce the number of bug reports made with PHP 4.2.0+ installations. This was seen as a temporary measure at the time to have a proper register_globals compatible solution before the 2.2 release was finalized.

The requirement for register_globals was fixed with a proper solution in July 2003 during the development of osCommerce 2.2 Milestone 3. As this was just one of the major incompatibilities to osCommerce 2.2 Milestone 2 it was later decided to completely break compatibility for further improvements and continue onwards to a 3.0 release.

Due to the long development period for 2.2 Milestone 3 / 3.0, it unfortunately kept the register_globals requirement active on the 2.2 Milestone 2 release during this time and will be finally fixed for the final 2.2 release. The fix is covered by a compatibility layer and can only be active on PHP 4.3+ installations. This is to keep compatibility with the add-ons available where advancements to PHP that are used for the compatibility layer are available since 4.3.0. It is not possible to implement a fix for lower PHP versions without breaking compatibility with the available add-ons.

This allows 2.2 to be still used on servers running PHP 3+, PHP 4+, and PHP 5+ with register_globals enabled, and optionally on PHP 4.3+ and PHP 5+ with register_globals disabled. This makes the 2.2 release more interesting even though it is an old release simply because it is a widely used, community supported (4,000+ add-ons!), mature, and secure solution that is a viable alternative to the next generation 3.0 version once it is finalized and released.

The changes for existing installations can be seen here:

http://svn.oscommerce.com/fisheye/changelog/osCommerce/?cs=1583
http://svn.oscommerce.com/fisheye/changelog/osCommerce/?cs=1584

register_globals has lived the past few years with a bad reputation simply due to bad programming or learning from examples at a time where security was not an issue as it is today. The osCommerce 2.2 Milestone 2 release was a big step towards a secure codebase and has not been affected by register_globals vulnerabilities that other PHP solutions have been affected by, even that it requires it to be enabled.

osCommerce 3.0 will work on servers with register_globals enabled or disabled, and disables it at run-time if it is enabled. This is to pass secure coding standards onto developers for the add-ons they develop and make available, and is in preparation for future releases when register_globals is removed from PHP 6.0.

Categories: osCommerce Tags:

Who’s Online and the Administrator Log

March 30th, 2007 Harald Ponce de Leon Comments off

We’re looking at releasing osCommerce 3.0 Alpha 4 tonight (Friday 30th March CEST). Although the roadmap entries for this release were finalized a while ago, some standard updates were performed on the framework to get both the Administration Tool and Catalog sides on par with each other. This left our Lebkuchen somewhat longer in the oven than planned but man does it taste and look real good now :)

One of the last pieces of work that was developed for this release was the migration of the Administration Tool language definitions to the new ini style format that was introduced for the installation routine. This was done in preparation for the HTML E-Mails roadmap entry for 3.0 Alpha 5 where e-mails can be sent out in the language the customer has selected. By moving to the ini style format for the language definitions, it allows us to overwrite definitions with another language set at run-time which was not previously possible with the use of PHP constants.

Getting this work in now for the 3.0 Alpha 4 release gives it a greater audience for aggressive testing rather than leaving it for the 3.0 Alpha 5 release.

The 3.0 Alpha 4 release is also a great starting point for developers to start getting familiar with in regards to creating add-ons for it. Although there are still framework changes planned that will make the add-ons incompatible with the final 3.0 release, we hope to receive a lot of feedback from developers with how their experience with the release went, and how to further improve the framework to make it even easier to integrate add-ons for the final 3.0 release.

To kill time in waiting for the release to occur here are two movies demonstrating the Who’s Online page with the MaxMind GeoIP Country Lite module activated, and a second movie demonstrating the new Administrator Log section, customer address book administration page, and batch job capabilities.

Who’s Online Movie

Thanks to the MaxMind GeoIP Country Lite module, it is now possible to see the country flag as icons beside each customer entry, as well as additional information to the IP address which is GeoIP module dependent.

It’s also now possible to delete active customer sessions via the Who’s Online page. Although such functionality is available, it must obviously be used with extreme care.

Administrator Log Movie

The visual representation of customers is also improved by showing gender specific icons next to each customer and address book entry. This makes it easier to address the customer correctly when contacting them directly.

The introduction of the Administrator Log feature shows what database modifications were performed by which administrator. The logging information helps when a mistake was made and can be backtraced to who made the change and when. Administrators that have access to this section only see the entries to the sections they themselves have access to, and can be filtered together with a specific administrator.

The different coloured backgrounds for the Administrator Log entries mean the following:

  • Green: inserted database field
  • Orange: modified database field
  • Red: deleted database field

The introduction of the Batch Job Capabilities feature brings in new checkboxes to the table listings on each Administration Tool section where actions can be performed on many entries at once. Newer actions such as exporting will be introduced in the next alpha development releases.

Categories: osCommerce Tags:

The Lebkuchen Is Still In The Oven

March 6th, 2007 Harald Ponce de Leon Comments off

The core roadmap entries for the 3.0 Alpha 4 release have been finalized today in trunk on the development repository. There is still some cleaning up to do and some tickets to still take care of, which means a public release of 3.0 Alpha 4 is just around the corner.

As most of the changes in the 3.0 Alpha 4 release are with framework improvements, the coolest feature that can be seen is the new Administrators Log section on the Administration Tool. This section displays all database modifications performed on the Administration Tool and can be used with a simple call to the database class:

$Query = $osC_Database->query('update :table_customers set customers_firstname = :customers_firstname where customers_id = :customers_id');
$Query->bindTable(':table_customers', TABLE_CUSTOMERS);
$Query->bindValue(':customers_firstname', 'Joe');
$Query->bindInt(':customers_id', 1);
$Query->setLogging('customers', 1);
$Query->execute();

The parameters passed to the setLogging() class method are the section of the Administration Tool the modification is occurring from (”customers” being the Customers section) and the ID of the database record (optional). The query above would log the old value of the customers first name and the new value in the administrators_log database table.

The Administrators Log feature is used together with the Administrators Access Levels implementation and serves to keep the store owner up to date with modifications other administrators have performed.

The output of the Administrators Log is currently rather raw and will be improved in later releases where modules can display the data in a more human readable format.

A movie presenting the Administrators Log feature will be posted in the coming days.

We are also now registered at the CIA site that displays the activity occurring on the development repository server. Commit changes are also now displayed in the development IRC chat room in real-time.

Categories: osCommerce Tags: