modifying osCommerce

I have not done osCommerce development in many years. Please check osCommerce partners if you need osCommerce assistance.

The purpose of this article is to provide and overview of the software at the file level so that anyone needing to address osC in modification/troubleshooting has an idea of where to look.

About osCommerce:

osCommerce is a free storefront web application written in PHP. It offers a variety of setup options, but as the case with almost any store there will be very specific business needs that need to be addressed.

Avoid osCommerce if you can

“Out of the Box” Shopping Cart software generally sucks. If you’re posed with the question of “should I use a prepackaged store or just write my own?” definitely write your own according to your business objectives.

However, if you’re forced into using something out of the box—you’ll need to know how to modify the software. Modifying code that other people wrote is generally tedious, especially if the software is written rather creatively and not exactly well documented.

My Experience

Recently I was charged with salvaging a project that involved osCommerce and I’m going to write a guide that I wish I had the first day in hopes of saving someone else a ton of time. The most involved I got with osCommerce was modifying the shopping cart and checkout process so that customers could select varying shipping addresses for the same order. Almost all of my modifications were made to the checkout process and with the product info/add to cart screen.

The important files

“Y’know, there’s a better way…”

osC has product attributes built in to the administration. The software is very customizable from the administration interface. However, the admin interface (and several community modifications) did not come close to meeting our needs so I had to dive into the code. I think my story is very similar to a lot of past, present and future osC users.

Where’s the rest?

The other parts of this article deal with specific modifications (part 2-functions, cases, blocks oh my) and analysis (part 3-analysis, finding ROI for your store).

The modifications I made dealt with customizing shipping to be per product ordered. They fell under these categories:

Before We Code

It’s imperative to have a clearly defined plan for what additional data we’re storing. It’s also a good idea to have the database tables already modified.

The only table I ended up modifying was orders_products. I added fields like greeting, customers_shipping_id, discounts, and shipping_date.

There was only one table that I created (that was related to my modification): customers_shipping (customers_shipping_id PK, customer_id, shipping_name, shipping_address1, shipping_address2, shipping_city, shipping_state, shipping_zip)

Product Display

The file we’ll be looking at is product_info.php. Not a lot of osCommerce specific modifications happened here. I just plugged in specific PHP code for the user to select a shipping method, a destination, greeting, and a shipping date.

Shopping Cart

It’s good to understand the process that osC uses for a shopping experience.

Selecting “add to cart” from product_info.php goes through this process:

  1. hits application_top.php with a HTTP GET of action “add_product”.
  2. flies to the switch case statement for $action which is: switch ($HTTP_GET_VARS[‘action’]) {
  3. goes to “add_product”:

The Shopping Cart has a few functions.

Found in includes/classes/shopping_cart.php

restore_contents()—does a restoration of shopping cart contents based on your shopping “basket”—the previous items you added to your cart with a login/password but did not check out.

notes: if you are a guest on the cart and you have products, when you log in their contents are added to your “basket”—as well as each additional product you add to your cart until checkout.

Additions I made here were mainly adding fields to be inserted into the “basket” (customers_shipping_id, greeting, shipping_date, shipping_id) I also changed the cart object that is returned here ($this->contents[$products[‘products_id’]]) to contain shipping_date, shipping_id, greeting and customers_shipping_id.

add_cart($products_id, $qty = ‘1’, $attributes = ‘’, $notify = true)—adds the product to your cart.

notes: if we’re dealing with a logged in session, add it to the basket (database) as well as the cart (sessions)

get_products()—provides a list of all products in the cart.

Once a user has items in the shopping cart, we go to the checkout process:

in includes/classes/order.php you’ll find a few functions.

cart()—transfers what was in the the shopping cart into an order.
query()—writes the order to the DB.
order()—initializes and calls cart()

The order then passes to a payment module, we used Authorize.NET AIM…

Methods in includes/classes/modules/payment/authorizenetaim.php

pre_confirmation_check()—runs a basic CC validation algorithm ( does not actually CHARGE the card )

before_process()—hits authorize.net VIA cURL and returns $response which is a pipe delimited string that has specifications “here:http://www.authorize.net/support/AIM_guide.pdf

To Change what username or password this module uses, the easiest way to go is via /catadmin/ and go to Modules > Payment > Authorize.net AIM

Ordering

This is where the bulk of the work I did was – the main files we’re dealing with are prefixed with checkout_.

The main pointer I can give with dealing with the checkout_ files is realize they all hit application_top.php first before spitting back to the actual page.

Database Notes

address_book—contains the default billing address for customers. address_book was originally intended for multiple shipping addresses, but not at the product level and didn’t provide enough flexibility.

categories—contains all of the categories and their “parent” categories. some redundancy.

categories_description—all of the names of the categories and their text descriptions that display on individual category pages.

customers—customer database. only really deals with osCommerce logins contains new customer email addresses. only important to osCommerce.

customers_basket—contains “shopping basket” for customers. i added shipping_date, greeting, customers_shipping_id, and shipping_id to this table.

orders—used in displaying order history. is the osCommerce orders table.

orders_products—modified with additions of shipping_date, greeting, users_shipping_id, and shipping_id (users_shipping_id == customers_shipping_id)

In Closing…

osCommerce is not so bad to modify if you have a clear plan. However, I really question some of the methods they use to iterate through products, like no foreach() loops!

Part 3 will be about analysis of your shopping cart. I’ll show you how to plug osCommerce into Google Analytics so that you can show your stakeholders great data on your store’s success.

Now that you have a fully functional ecommerce store up with osCommerce, how can the store make more money? The key is to learn the most you can about your customers. The most eye opening experience I had in Kansas City: a well targeted advertisement can go a long way. Targeting is the hard part.

At the end of this tutorial you should be able to answer these questions:

If you’re using Google AdWords in a PPC campaign…

Luckily, all of the data analysis has been done by Google/Urchin engineers. We just have to fit our store to their specifications. I’ll get to that later.

In an online store there is a point in a checkout process called a *“conversion point”*. A typical checkout process goes like this:

  1. Enter Shipping / Billing Information (checkout_shipping.php)
  2. Enter Payment Information (checkout_payment.php)
  3. Verify Order Contents (checkout_confirmation.php) -> (checkout_process.php)
  4. Yay! Smiley! Your order is complete. Thank you emails and invoices can be sent from this point, too. (checkout_success.php)

Point #4 is the conversion point. The order is complete. The visitor to the site is now a customer. This is a very important transformation for analysis. In osCommerce, this page is checkout_success.php.

Unfortunately, osCommerce ditches the $order object’s contents (presumably for security reasons) in checkout_process.php. At the top of checkout_process.php I added a line:

$_SESSION[‘orderData’] = serialize($order);

Since we’re using session based variables we have to serialize the object and unserialize the object. I won’t get into why we have to do that here…

So now, on checkout_success.php we can access our $orderData object like this:

$orderdata = unserialize($_SESSION[‘orderData’]);

We need the contents of the $orderData object to pass to Google Analytics.

The way Google Analytics works:

CAVEAT: Yes, you will miss order data from users that have JavaScript disabled. It’s unfortunate, but since Google Analytics is free and handles ecommerce better than some of the paid solutions out there… that’s something I’m willing to deal with.

Google Analytics has a good guide in regards to code to add to checkout_success.php.
Basically, the lines that start with UTM:T are transactions and UTM:I are items within the transaction. Just loop through your $orderData object and fit your data to Google’s syntax. It’s that simple. Now watch the money come in…

Google Analytics’ ecommerce tracking takes care of the heavy lifting for you.

ecommerce-revenue_transactions.pngRevenue by Transaction

ecommerce_revenue-source.png
Revenue By Source

The answers to all of the questions posed at the beginning of this article can be found in Analytics’ Ecommerce section.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Back to Andy Hill's homepage