osCommerce Blog

You may be wondering why I have not kept up with the site of the month posts. Recently, a featured store option has been added on to the live shops directory. Now, instead of sites of the month, I will be proposing featured sites to the rest of the osCommerce team. When I do select a featured site, I will also blog about why I choose that site if it is approved by the rest of the team.

I will be starting a series of blog entries geared towards small business owners looking to bring their business online with osCommerce.

For my first entry I will be discussing the advantages of the internet and how the internet can benefit small business owners.

Before building an online presence a small business owner must understand the benefits and drawbacks of building a website/ online store.

One of the major advantages of having an online store or website is that information is available to customers 24/7. This is an important aspect of the web that is often overlooked. As a customer, if I wanted information about a company that does not have a web site I would have to wait until they opened to call them. Even then, I may have to deal with an annoying animated phone system or answering machine. The internet, combined with e-mail, allows potential clients or customers to learn what they need to know at their convenience.

What are some other major advantages of having a store online? One major advantage is the reduction of marketing costs. Putting marketing information online saves the business owner a lot of money.

In addition to reducing marketing costs, websites also reduce support costs. A business owner can save money by using the Web to provide support when staff is not available. For instance, a business owner can integrate a Frequently Asked Questions module into their store which will assists in answering customer questions.

Websites also give companies a modern image. Having a .com and a company email address gives the impression that your business is current and up to date on technology. However, if you are creating a Web presence solely based on this decision then you must determine if that is enough of a benefit to justify the costs of going online.

Finally, creating an online store and/or website will greatly help with your company image. A professionally designed website can make your company look important and impressive.  For instance, positive product reviews left on your online store can dramatically improve your company image.

My next blog entry will cover the disadvantages of the web. Poorly designed web sites, web sites that are incomplete and web sites that are partially under construction can have a negative effect on company image. Many home-based or low-budget website fit this category. All too often when reviewing Live Shop entries I see stores that fit this category. These sites do more harm to the business then good.

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.

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.