osCommerce Blog

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.

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.

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.