#oscom30

Lots has happened during the week! Here is a summary of some of the events:

UTF-8 issues: Laurent discovered that PHP does not report errors in UTF-8 and brings problems to our custom ErrorHandler class which logs errors in an SQLite3 database and is retrieved via JSON. Both SQLite3 and JSON require valid UTF-8 sequences. This problem can arise if PHP reports errors in a foreign language. The bug report is #259. A solution is still being looked into.

Some reports of MYSQL_ATTR_INIT_COMMAND being undefined have been submitted. This is a PHP v5.3.0 bug that only affects Windows. No work around will be provided so the solution is to upgrade the WAMP solution being used to a version using PHP v5.3.1 or later.

Our Bug Reporter now has separate categories for OSCOM v2.x and v3.x.

SessionAbstract now checks if the supplied session ID in GET/POST/COOKIE exists. If it does not exist, it ignores the supplied value and generates a new session ID to use.

Support for Site Domains will be introduced in v3.0.2, which allows each Site to have its own http server and cookie domain settings. For example, this allows Shop and Admin to be called as: http://shop.oscommerce.com/index.php, and http://admin.oscommerce.com/index.php (?Admin is not needed) Sites that require cookies to be shared must have proper cookie domain settings (eg, ".oscommerce.com"). OSCOM::getDefaultSite() now checks against $_SERVER['SERVER_NAME'] to load the appropriate Site and default Site Application. OSCOM::getLink() automatically generates correctly formed URLs to Sites with different domains.

Some reports of OSCOM v3.0 not working with PHP v6.0-dev have been submitted. This is due to an old version of PHP v6.0-dev being used that does not support namespaces. According to this LWN article from March 2010, work on PHP v6.0-dev has been pushed to a separate branch and is no longer part of the main PHP development path. I downloaded the latest trunk version of PHP from their subversion development repository, compiled it, installed it, ran OSCOM v3.0.1 on it, and can happily report that it works superbly without any errors being reported! The version PHP reported is PHP v5.3.99-dev / Zend v2.4.0 and will be PHP v5.4 once released. This version finally removes deprecated functions and settings that still exist in PHP v5.3.

Work on a Phing build script has been started to build, test (PHPUnit), and package (ZIP) OSCOM download releases. Ultimately this will automatically build full download release packages, manual upgrade packages, and CoreUpdate Phar update packages.

One of the great new features of our framework is the ability to perform upgrades via the Admin Dashboard, where update packages are listed, modified files can be seen, and upgrades can be performed at the click of a button.

Unfortunately not everyone will get to experience how great this can work with the v3.0.1 release as CoreUpdate in v3.0 can detect incorrect file permissions under certain server environments during an upgrade procedure, and reports back of a successful upgrade when no files were updated at all. This affects you if after the upgrade to v3.0.1, v3.0.1 is still listed as an available update package to upgrade to.

Those affected can download the manual v3.0-to-v3.0.1 upgrade package to extract and copy over to their installation via FTP. Although also an easy procedure, this is not the kind of experience we want to share with you when upgrading.

We've taken this opportunity to improve CoreUpdate in v3.0.1 and are extremely pleased with how it now handles upgrades.

CoreUpdate utilizes Phar to download signed phar update packages from our server, to list the contents of the update package to show which files are going to be modified, and to extract the files over the installation to perform the upgrade.

It sounds easy, but when file permissions become an issue, Phar panics and produces a fatal error that can stop further processing of PHP code.

We've improved CoreUpdate to better handle file permissions and situations where Phar can produce unexpected errors. Instead of just extracting files in an update package to the installation, CoreUpdate now tracks which files are going to be modified, backs those files up, extracts the updated files in place, and if all files have been successfully updated, goes back and deletes the older files no longer necessary. If an unexpected error occurs, CoreUpdate deletes the files that have been extracted and restores the original files automatically reverting to the original state.

There are a lot of server environments and file permissions CoreUpdate has to handle, and we're striving to make it "just work" to provide the best user experience as possible.

CoreUpdate is still in its infancy. We imagine that update packages can first be tried before an actual upgrade is performed, to test and make sure customizations continue to function as normal in a live environment. Phar allows this and we look forward to taking advantage of its full feature set to make this possible.

We know that feeling of pushing an "Upgrade" button and want to turn that fear into a pleasurable moment. We enjoy the challenges working with the strictest levels of error reporting to richen our creativity and produce even better code.

Published by Mark Evans

To follow-up to my previous posting about osCommerce and the BSD Licence I will now try and answer some of the misconceptions around the new CLA (Contributor License Agreement) which was added as part of the osCommerce 3.x release. I will also aim to make this into an official FAQ document when time allows...

Published by Mark Evans

There have been a number of comments made about the license change of osCommerce 3.x to the BSD. This post aims to dispel some of the confusion around the change and will hopefully be the primer for a proper FAQ on www.oscommerce.com when I have some time. If there are any questions you have...

This is the first of a multi-part series documenting the new framework architecture of osCommerce Online Merchant v3.0.

Those that have not been following the development of the new framework will receive quite a shock when they download the osCommerce Online Merchant v3.0 release package and start inspecting its source code. The new OO/MVC design approach will be completey foreign to those accustomed to the procedural style design v2.2 was based on. This is a new ballpark to play in, and it’s open for everyone to participate!

The first difference that will be seen is the new file and directory structure of the framework, specifically how clean it is. What’s provided is:

index.php

public/

osCommerce/

That’s it! The index.php file initiates the framework and the public directory holds site and template related images, stylesheets, javascript, and other assets that must be publicly available. The osCommerce directory is where the source code of the framework resides and is recommended to move to a PHP include directory that is outside of the public html directory serving the website.

The framework is initialized by the main OSCOM controller located at osCommerce/OM/Core/OSCOM.php. It’s main responsibility is to automatically load Sites, Applications, and Actions depending on the request URL.

Sites? Applications? Actions?

These are new modular sections of the framework that build the website. Correction, that build websites. The basis of the framework is flexible to support different kinds of websites, for example, a website content management system, a blog, a forum, etc., and with your help, will be improved on in future releases to support the building of such sites even easier. Our primary focus will remain on e-commerce - we can’t wait to see what the community builds in addition!

osCommerce Online Merchant v3.0 is built with the following four Sites:

Shop

Admin

RPC

Setup

The Shop Site is the frontend of the shop, the Admin Site is the administrative backend to the shop, the RPC Site manages JSON requests, and the Setup Site installs and configures new installations.

The first part of the request URL loads the specific Site. For example, the Shop Site would be loaded with the following URL:

http://demo.oscommerce.com/index.php?Shop

Sites are formed by areas packaged as Applications. The Shop Site includes the Account, Checkout, and Products Applications, and are loaded by the second part of the request URL:

http://demo.oscommerce.com/index.php?Shop&Account

Applications define the default page content to load and can be fine-tuned with Actions. Actions override the default loading page and can execute certain functionality that is loaded by the third part of the request URL. The log in page, which is part of the Account Application, can be loaded with the following URL:

http://demo.oscommerce.com/index.php?Shop&Account&LogIn

Actions are recursive - the processing of the log in page is performed by the following URL:

http://demo.oscommerce.com/index.php?Shop&Account&LogIn&Process

This allows new Sites, Applications, and Actions to be copied to the framework directory which work immediately without the need to edit core source code files.

The controllers loaded for the above examples are defined in the following file and directory structure:

osCommerce/OM/Core/Site/Shop/Controller.php osCommerce/OM/Core/Site/Shop/Application/Account/Controller.php osCommerce/OM/Core/Site/Shop/Application/Account/Action/LogIn.php osCommerce/OM/Core/Site/Shop/Application/Account/Action/LogIn/Process.php

Sites and Applications are self contained. Its required classes are located in its Site and Application directories, and are accessible by other Sites and Applications.

A default Site is defined in the configuration to load for requested Sites that do not exist, and to shorten the URLs used within the default Site. The default Site for new installations is Shop allowing for the following shortened URL:

http://demo.oscommerce.com/index.php?Account&LogIn

This works only for Sites and Applications that do not share the same names. For example, the above URL would load the Account Application and LogIn Action from the Shop Site if no Account Site exists. If an Account Site exists, it would be loaded instead with its LogIn Application.

Custom modifications to the framework must be performed in the following directory:

osCommerce/OM/Custom/

This directory is empty for new installations and follows the same file and directory structure as the osCommerce/OM/Core/ directory. Before files are loaded from the Core directory, a check is performed to see if a matching named file exists in the Custom directory to load instead. This allows for any part of the core framework to be overridden and for the core framework to be easily updated to newer releases without losing custom modifications.

A script is available to check the minimum requirements and settings for osCommerce Online Merchant v3.0 on a PHP enabled webserver.

To check your server, download the following package from Github, unpack it, copy oscom_check.php to a public html directory on your server, and call it with your browser.

https://gist.github.com/gists/881326/download

An example output of the results can be seen at:

http://countdown.oscommerce.com/oscom_check.php

The biggest milestone in our history will be reached on March 31 2011 with the release of osCommerce Online Merchant v3.0. This is the result of years of hard work, community feedback, and patience! We thank the community and our partners tremendously for their support during this long development phase and look forward to working with you in achieving our goals for 2011.

Each piece of the puzzle we've blogged about previously has now come together and formed the framework as v3.0. The focus on this release is to provide a solid and flexible base that can be built on with exciting new core framework and user features, and to be easily extended on with Add-Ons.

Our vision is not to provide one or more full feature packed "enterprise-ready" solutions but to provide a solid core framework that can be easily customized and extended on to meet specific requirements.

The framework has finally reached the stage of being production-ready. The release date of March 31 was set to freeze and clean the API to provide a solid-as-possible framework to start building on. Most of the new exciting user features we had wished for v3.0 will not arrive with the initial release as it would have otherwise delayed the release even longer. We strived for perfection and are now delivering as fantastic.

Our release strategy is now changing from delaying releases until a set number of new features are ready for production use, to pushing out new features as soon as they are ready. Features and bug fixes belong in products, not in development repositories!

The flexibility of the framework allows us to release early, release often without conflicting with customizations. Updates are safely applied through the Administration Dashboard after displaying which core files are to be modified. Customizations are performed in a separate namespace that override core framework functionality.

The level of hard work does not stop on March 31 but will continue strongly throughout April and coming months to push out regular update releases that fix bug reports and introduce user features that did not make it for the v3.0 release.

April will be an extremely busy and exciting month we can't wait for!

Our versioning scheme is now improving from no longer publishing Preview, Milestone, Release Candidate, Alpha, or Beta releases but fully supported production-ready releases. Each version number will be in the form of X.Y.Z (eg, 3.0.0) where X is increased for major incompatible releases, Y for minor API changes, and Z for bug fixes and new features that don't break compatibility to earlier versions.

Each API change will be documented for developers to review.

From April we are going to:

Be active in the community to help developers understand the framework and store owners its user features

Update remaining Applications and Modules that were not finalized for the v3.0 release

Provide a database import tool for existing v2.2RC2, v2.3.1 and v3.0A5 users

Start a localization site for translators to use and build language translation packages

Document v3.0 framework and user features

Finalize MS SQL Server database abstraction queries

Extend the CoreUpdate Application to also support installed Add-Ons

Allow Phar packaged Add-Ons to be tested without the need to install them first

Continually improve existing features and introduce exciting new features

In addition we are looking for new talent to help us:

Improve overall UI design

Support database servers with our abstracted queries

Continue to improve the core framework