#native_company# #native_desc#

Cross-platform and Portable Development With PHP

By PHP Builder Staff
on July 20, 2001

Building an E-Commerce Website On Windows and Unix/Linux: Cross-platform and Portable Development With PHP


We have recently built and delivered an e-commerce project which runs both on Linux and Windows, talking optionally to either Microsoft SQL Server or MySQL. The software was built with PHP4 and is now deployed on a Windows NT server under IIS and SQL server. It runs equally happily (and somewhat faster) on Linux and MySQL.
We thought there might be some people who would like to know a little about how it was done.


The project objectives themselves were not out of the ordinary. We had to build a site for industrial use which would allow a database of products, prices and discount matrices to be accessed by registered users. The users should be able to place orders, review order status and carry out typical shopping-basket operations of the kind you would see on a many on-line ordering sites. Although the site wouldn’t be allowed to connect to the live enterprise resource planning system (security concerns were amongst some of the reasons) it would receive regular stock updates and should try to provide a good indication of current stock levels.
The particular project objectives aren’t all that important. The technically interesting aspects are the cross-platform solution that evolved.
Our customer was keen that any solution should be able to run equally well on Linux or Windows NT and that it should be independent of the database product as far as possible. Various commercial constraints meant that it would inevitably be deployed on NT/IIS with the data stored in a SQL Server database. A particular concern of the implementation was that the database would NOT be local to the web server, but instead accessed physically remotely via the corporate internal WAN. The WAN is known to have limited bandwidth and to get busy from time to time.
Flexibility and portability being important matters, we concluded that a solution based on either Perl or PHP would be the best bet and elected to use PHP since it was easier to convince some sceptics that PHP was a mature product in the NT environment. The situation was politically sensitive (spot the understatement) and whilst we would have been happy with either choice, the art of the possible pointed towards PHP. (Our developers still prefer Perl by the way).