The new site will be rolled out in 3 stages with the first stage contemplating the existing contributions section. In addition, community members and developers can help clean the structure of add-on packages by reporting uploads to be removed.

The following changes are planned for the second and third stages of updating the new site:

2nd Stage Updates:

• register_globals compatibility flag for 2.2-RC1 and 2.2-Final installations
• Maintainers can assign their add-ons as public or private to allow or disallow additional uploads from other community members
• If an add-on is private, maintainers can assign other community members as maintainers who are allowed to upload files to the package

3rd Stage Updates:

• Allow maintainers to edit descriptions
• Allow maintainers to link their uploads to a forum topic (for support)
• Allow maintainers to upload screenshots of the add-on in action
• Allow maintainers to link to other add-ons as a “related” feature
• Allow community members to adopt an inactive add-on

The new community add-ons site can be reached at:

http://addons.oscommerce.com

We look forward to rolling out the additional features in the coming weeks and look forward to the additional suggestions the community has for improving the experience of finding, downloading, and contributing additional add-on packages.

This allows modules to be created to define new data parameters for a product which can easily be accessed via its module code.

Once a product attribute module has been installed via the Administration Tool (in the same manner payment and shipping modules are installed), its field is automatically added to the edit product page where the module controls the presentation of having its value defined.

This allows add-ons to be installed that add data fields to the product without the need to modify the edit product page in order to save the data in the database.

A minor change to the database class has also been performed to automatically bind the database table names in SQL queries which allows any database table to be accessed without the need to define it first in the includes/database_tables.php file. (This file will be removed in the 3.0 release)

Here is a short QuickTime movie showing the new Product Attributes feature with the following attribute modules:

1) Date Available (javascript controlled input field)
2) Manufacturer (pull down menu)
3) Shipping Availability (pull down menu)

osCommerce Online Merchant Product Attributes QuickTime Movie; 1.1MB

The product information page on the store front-end has also been updated to allow the dynamic product variant combination values to control certain data on the page, such as the product price and the product model.

osCommerce Online Merchant Product Info Page

The introduction of the new Product Attributes feature is currently defined for master products only, which product variants will use, and will be definable at the product variants level once the edit product page has been redesigned to handle the presentation of the data.

Here is a short QuickTime movie showing how product variants are created for a t-shirt product, and extended on by providing custom variant values:

osCommerce Online Merchant Product Variants QuickTime Movie; 3.7MB

The primary change to support custom variant values went into the shopping cart class where it referenced each product in the shopping cart via its product ID. This brought in a limitation where it was not possible for a customer to add a t-shirt with different custom text values to their shopping cart incase they wanted to order the same t-shirt multiple times with different texts.

To allow this behaviour, each product in the shopping cart is now referenced by an automatically generated, customer specific, item ID where it is possible to order multiple quantities of a product, and now possible to order a product multiple times with different custom variant values.

osCommerce Online Merchant Product Info Page

It is now possible to mark a product variant as the default product variant on the Administration Tool to have default values already selected on the product information page. This shows above with the “Size” pull down selection list and the “Colour” radio button choices.

As this product accepts custom values, each time it is added to the shopping cart it is treated as a separate product in the shopping cart contents. This allows the product to be added multiple times with the same variant combination values but with different custom text values.

osCommerce Online Merchant Shopping Cart Page

This behaviour only applies to products with custom variant values where adding a normal standard product to the shopping cart multiple times would increment its quantity value.

The parsing of the product variant combinations are performed by modules assigned to the variant group, which can easily extend the behaviour of product variants to suit ones needs. This modular implementation has also introduced our first PHP 5 optimized abstract class which forces modules to follow an operation standard.

To further extend the Product Variants feature, we will also be looking at making it possible for customers to upload files when adding products to their shopping cart. This builds on the custom text possibility for t-shirts where logos and images can be attached to an order. The next set of changes will finalize the implementation for the 3.0 Alpha 5 release and be committed to /trunk/, with the file upload extension being looked into for the 3.0 Alpha 6 release.

This allows the quantity, price, model, weight, status, and other product data information to be assigned distinctively to each variant a product has. As each variant has its own product record, referencing a product with a specific variant combination is easily performed with the product ID.

This is an extreme improvement over the previous implementation where specific attribute combinations were referenced with a string value containing the product ID and the various attribute group and attribute value IDs (eg, 14{2}14{5}256).

Here is a short QuickTime movie demonstrating how Product Variants are defined on the Administration Tool and how they are handled on the Online Store:

osCommerce Online Merchant Product Variants QuickTime Movie; 1.6MB

The Administration Tool product listing identifies products containing variants and graphically distinguishes the records to normal product records:

osCommerce Online Merchant Administration Tool Product Listing

The price range for the product variants (the minimum and maximum prices) are shown in the product listing as well as the number of total quantities the master product has.

Defining variants for a product can be performed by clicking on an “Add Variant” action button and by double clicking on the variant values to add:

osCommerce Online Merchant Administration Tool Product Variants

The product variant combinations are held within javascript values and are first saved (or deleted) when saving the product record.

The Online Store also distinguishes between normal products and products with variants by showing either the full product price for normal products, or the minimum price for products with variations:

osCommerce Online Merchant Product Variant Pricing

The Product Variants feature has been freshly committed to my subversion development branch and will be merged to trunk as soon as the implementation is finalized. The interaction with product variants on the product information page is being finalized and will be showcased later this week with another blogging entry.

If you’re keeping up to date with my development branch, please take a look at the changes and provide feedback on the community forums. Thanks!

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.

<?php
  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:

<?php
  $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:

<?php
  $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.

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.

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.

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.

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.

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.