eMart E-Commerce Solution.

The implementation of the project was carried out solely by myself and was completed within a two-week timeframe. All code is my own.

The mission statement.

“The purpose of the system was to provide a complete and comprehensive database system with an easy to use interface for an online retailer of grocery goods. The database would collect, store, manage and control access to the data for stock management, customer orders, HR management, and company finances.”

Expanding on the project mission statement, the project involved creating a web interface incorporating a database for customers to browse and purchase products online from eMart. The system was also extended to all eMart employees to control stock management and deal with customer orders.

The system achievements.

The final web application developed was a high quality ecommerce solution that is fully functional and able to process credit card transactions through an encrypted pipeline. A live demo site is viewable via the 'launch project' link above. The Administrative back-end can be accessed with the following login credentials:

  • Username: sysadmin
  • Password: Password2012

Custom error handling.

With the help of a consistent, comprehendible, custom error-handling object and a powerful relational database, data integrity is ensured and any errors that arise in the system are capably handled without complete system failure. Errors are output to a text file, errors_log.txt located in the logs directory.

Code structure.

When building the system, the decision was made to implement a flexible architecture composed of “pluggable” components. This enabled the adding of new features, such as the shopping cart summary, departments list, customer account/login summary by coding them as separate components and plugging them into the existing application.

In keeping with the MVC architecture of the system the source code developed is separated into a presentation, business and data layer. The presentation layer contains the UI elements of the system and includes all the logic that manages the interaction between the user and the system. This layer is composed of the dynamic web pages (PHP and HTML template files). The business layer receives requests from the presentation layer and returns a result to the presentation layer depending on the business logic it contains. Almost any event that happens in the presentation layer usually results in the business layer being invoked, except events that can be handled by the presentation layer, for example, simple input validation. For example, if the eMart employee clicks to retrieve the 20 most recent orders in the database, the presentation layer invokes the business tier with a message, ‘Please send me all orders that match this query’. Usually, the business layer needs to call a stored procedure in the data layer for information to be able to respond to the presentation layer’s request. The data layer is responsible for managing the application’s data and sending it to the business layer when requested.

The system implemented made use of a template engine, Smarty, which offered a framework for separating the presentation logic from the static HTML templates. Smarty is, to date, the most powerful template engine for PHP. Ideally, it would of proved advantageous when assigning coding ‘jobs’ to members of the team (were there enough bodies), allowing one person to work on the HTML template designs independently from the PHP programmer. This is because the PHP logic can be altered without needing to change the template files, and vice versa.

Communication between the PHP code and the MySQL database was achieved via the PHP Data Objects (PDO) extension tool. PDO offers a uniform way of accessing a variety of data sources (i.e. MySQL, MS SQL, etc). By using PDO, the system’s portability and flexibility is increased since if the database changes, the effects on the code to access the data are kept to a minimum, with, in most cases only a change to the connection string necessary.


Only customers with registered accounts will be able to place orders. All orders require valid credit card information which is encrypted upon adding to the database. Customer credit card transactions are processed by an online payment gateway, authorize.net. This is fully functional in the product being submitted and processes dummy payments. The algorithm used for encryption of the sensitive information is the Rijndael symmetric key algorithm. A secret key constant is defined along with an initialisation vector. An encryption function encrypts the plain text received as a parameter and returns the result in hexadecimal format. A subsequent decryption function is also used that decrypts the encrypted string.

The system has a SecureCard class that represents an instance of a customer credit card. This class can be supplied with credit card information, which is then accessible in encrypted format. This class can also take encrypted credit card data and supply access to the decrypted information.

All passwords used throughout the system are stored using the sha1 hashing function. It takes as parameters a password string and a prefix and returns a hashed result ready for use. Since a hashing function is irreversible the original password is stored should the event arise that a password needs to be recovered.

Search engine optimisation

Keyword rich URLs were implemented with the use of various rewrite rules in the htaccess file and a function in the Link class that uses regular expressions to replace the characters that are not wanted in the URL, such as whitespace, with dashes. For example, the function would transform the string ‘Fresh Merseyside Butter’ with a URL friendly string such as ‘Fresh-Merseyside-Butter’. This is an added extra that provides a great means of search engine optimisation.

Custom built shopping cart.

The system has a custom built shopping cart. The benefits of this by far outweighed the alternative third party cart facilities, like those supplied by PayPal. Since the project set out to build a scalable system the ability to save order details was most advantageous. It opens up the prospect of adding features such as a product ranking system which would not be possible were we not to possess any data. The shopping cart has a ‘save for later’ facility. This facility allows a customer to order only a subset of the products in their shopping cart and save the other items ready to be purchased at a later date. When a product is saved for later, it is moved to a separate list of the shopping cart and is not included in the order when the customer checks out.

Order processing.

Implemented is a set of customer order-processing stages that deals with credit card authorisation (via authorize.net), stock checking, despatching orders, taking payments, and email notification. The order-processing functionality allows the tracking of orders at every stage of the process and provides auditing information that can be referenced at any point in time.

I am happy to forward the code for the system on to anyone that wishes to view it. Please just drop me a message :).

  • COMP208, University of Liverpool
  • Spring 2012
Launch Project