Building a shopping cart...from scratch...

[invision2]

Hey all!

Sorry for such a long post.

Deep breath.......
I'm building a shopping cart from scratch which will ultimately plug into Protx. I've built a few PHP/MySQL apps previously but not with 'da money' involved. I'm having echoes of Michael from 'Office Space' saying "I must have added an extra zero, I always do that".

Anyway, one part I'm confused over, I wonder how easy it is to store cart information, even when the user closes his/her browser. So when they come back and look in their cart, it still displays all the products added to the cart previously.
Should I be looking to cookies rather than sessions, or set a long timeout for my sessions?

For this cart/site, the user can add a number of products to his/her cart. Different types of one 'product', like a green car, red car or a red boat, blue boat etc. The 'car' being the product.

Should I be using sessions and arrays for storing the different products and their attributes? Each product will have some fairly detailed info with it, based on what the user submits the form, which will all just go into the title/description bit.

I just wanted to get the advice of the pro's here.

My idea for the SQL tables would be:

CUSTOMERS (username, password, email)
ORDERS(order_id, customer_id, total, order_date, approved)
ORDER_CONTENTS(oc_id, order_id, item_id, description, qty, price)
PRODUCTS (item_id, title, price)

And in terms of scripts, I was thinking:

cart.php - to display the current products in my cart (using session data)
update.php - change the quantity of products
add.php - adds items to my cart
remove.php - removes product from cart
checkout.php - takes all my cart/user data and sends it to Protx

Does this sound like a good procedure to start with?
Anything obvious I'm missing?

If anyone can give me one or two pointers for starting the 'add.php' and 'cart.php' I'd be eternally grateful.


Everything else should be fairly straightforward I guess .


Thank you

[PCSpectra]

Store cart details in a SESSION, yes. Tweak the session variables that determine the lifespan of the cookie which holds the SID and when the user revisits next time, they should still have their cart data populated.

[Itch]

I disagree. What if someone comes back a week later? Are you going to keep the session timeout longer than a week? You'll have to store the cart details in the database IMO.

[023-jimmy]

Maybe this is a suggestion:

-> When the user gets to the site. Generate a random id for the user and save this in a cookie.
-> When the user places a order, add the order in a database and include the generated id.

-> When the user comes back to the site again. You can check if the cookie, which holds the generated id, is set. If not you generate a new id and place it in a cookie again.

[decowski]

If you want a permanent cart then store its contents in the database.

Also I'd change your schema as follows:

CUSTOMERS (email PK, password) — email is a unique id anyway so don't make your customers remember another piece of information which is username

ORDERS(order_id PK, email FK, order_date, approved) — replaced customer_id with email FK and removed total, which can be easily calculated and including it here may lead to data inconsistency later

ORDER_CONTENTS(order_id PK, item_id PK FK, qty, price) — order_id and item_id make a natural compound primary key so no need to create an artificial one, no need to store description — this belongs to products table

PRODUCTS (item_id PK, title, price)

[invision2]

Store cart details in a SESSION, yes. Tweak the session variables that determine the lifespan of the cookie which holds the SID and when the user revisits next time, they should still have their cart data populated.

Eeek, sounds tricky.


Hey decowski, thanks for the reply!

Cool. So if a 'guest' starts adding things to their cart, I should store their session id and cart information in the database whilst they're roaming the site. What other data should be stored so if they come back later that day, they'll find the same cart?

My main concerns are if the 'guest' user suddenly closes their window, even though they had a pretty extensive cart(full o the moolah!).



Also, just to follow-up on this query I had:

Should I be using sessions and arrays for storing the different products and their attributes? Each product will have some fairly detailed info with it, based on what the user submits the form, which will all just go into the title/description bit.

How do I best store this data in the cart?
For example, a 'car' may have the following attributes: miles, fuel type.
Whereas a 'bus' may just have: miles, size.

The different attributes will have different values, so my cart could potentially look like:

Jen's Car | 300miles | Petrol  -  400GBP
Mike's Car | 200miles | Petrol - 300GBP
Paul's Bus | 250miles | Mini-Bus - 600GBP

Hope i'm not confusing things here.


Brilliant help so far, any further help would be much appreciated.

[decowski]

Cool. So if a 'guest' starts adding things to their cart, I should store their session id and cart information in the database whilst they're roaming the site. What other data should be stored so if they come back later that day, they'll find the same cart?

You can just generate a unique ID for each guest and store it in a cookie.

My main concerns are if the 'guest' user suddenly closes their window, even though they had a pretty extensive cart(full o the moolah!).

Well, you’ve got it all in the database.

Also, just to follow-up on this query I had:

How do I best store this data in the cart?
For example, a 'car' may have the following attributes: miles, fuel type.
Whereas a 'bus' may just have: miles, size.

Use a separate table, eg:

product_attribute
-----------------
product_id    
product_attribute
product_value

Of course you may want to break it down into multiple tables so that you don't have duplicate attribute/value pairs.

[invision2]

Thanks again for the reply Paul.

So in one of my include files I could have:

session_start();

if (!isset($uniq_id)) {
$uniq_id = srand((float) microtime() * 10000000);

// insert guest into db
$sql = "INSERT INTO temp_users(id) VALUES('$uniq_id')@;

$session['uniq_id'] = $uniq_id;

} 

which creates a unique number and puts it into a temporary SQL table?
So when they next come back, it'll have kept their cart data? Or do I need to store the unique session in the cart table?


And for my cart, how would I then relate this to the person's session?
Each ''product'' may have a number of different attributes to it. It's fairly tricky to explain.
Basically the customer 'creates' their products. So if they choose a car, they select 'Car', give it a name, the number of miles on the clock, engine size and the fuel type.
But, if they select 'Bus', they give it a name and select number of miles, and size.

So each 'product' has different number of attributes.


Sorry, you must think I'm pretty slow. I'm just struggling a bit to get my head around it all. I'm sure it's fairly simple, I'm just confused.

[AnthonySterling]

Just trying to figure out how I should store the data in the carts.

I wouldn't store this data in the cart, it's not really relevant.

Just store a unique ID for the product, then on your cart display page, just query the DB for the necessary meta data.

[decowski]

So in one of my include files I could have:

[snip]

which creates a unique number and puts it into a temporary SQL table?

http://uk2.php.net/uniqid

Yes, but there is no need for temp_users table. You can relate the uniqid in your cart table.

There are many ways of doing it, I'm giving you hints to make it as simple as possible.

And for my cart, how would I then relate this to the person's session?
Each ''product'' may have a number of different attributes to it. Car will have more attributes than Bus. Taxi will have more attributes than Bus but less than Car etc.

Just as I explained above but relate the attribute to cart item rather than inventory item.

[invision2]

Aaah of course, sorry, completely misread.

Looks like I will create a uniq_id for the guest. Perhaps have a 'temp_user' column in my cart table to store this value.
And also store a unique ID for the product that is created? Would this be inserted into the products table?

[AnthonySterling]

And also store a unique ID for the product that is created? Would this be inserted into the products table?

You could just use the unique ID that you use to store the product in the database, usually just 'id'.

[invision2]

Aaaah good shout Anthony.

However, I'm hoping to tie this in with the custom cart I've spoken to you before, where each 'item' is based on the user input. What s/he enters into the fields.

[023-jimmy]

What other data should be stored so if they come back later that day, they'll find the same cart?

-> When the user gets to the site. Generate a random id for the user and save this in a cookie.
-> When the user adds a item to his cart. Store this data in your mysql and include the generated id.

mysql_query("INSERT INTO `cart` (`product_name`, `userid`) values('". $product ."', '". $_COOKIE['userid'] ."')"); 

-> Now you can fetch the data from the cart, by using a SELECT query and use a WHERE to fetch the id that is stored in the cookie

mysql_query("SELECT * FROM `cart` WHERE `userid` = '". $_COOKIE['userid'] ."'"); 

Or.,

You can create a login/register system..

[joebert]

Set the expiration date on session cookies to a long period of time, set the session lifetime to be relatively short.
That way the server doesn't get clogged up with active sessions, and the browser/session-cookie will still send a reference to it later on.

With that in mind, take a look at the session_set_save_handler function, specifically the last $gc (garbage collector) argument. Be sure to check out the example usage that page has too.

Within that callback function, instead of unlinking/deleting old session files, you can move them to another directory and setup a cron job to clean out that other directory at a much longer interval than the PHP session directory gets cleaned. Closer to the expiration time of the cookie.

Now when you start a session on a page load, if you don't find something such as $_SESSION['active'], you can take the PHP session cookie from the visitor and look for that session file in the directory you're garbage collection function moves data to.

Don't forget to take privacy and security into consideration. With a setup like this it could be possible for someone to brute force, or guess at session IDs in order to hijack a session. I'm sure you'll figure out how to work around this by reading the rest of the session manual pages at php.net

[invision2]

Aaaah yes, the plan is that they will have to login/register at some stage, but I didn't want to force it on them until they were ready to checkout.
Would it make sense to ask them to register before they start adding items to their cart?

Wow, got a major headache from your post joebert. Will grab a coffee and come back

[invision2]

I like your idea 023-jimmy. I think I'll look to implement this.

But the way items are 'created' is down to the user. So each item is unique.
Just wondered how I then stored the item data in my 'cart' table before they check out?
The only essential item info is the price of each 'item', so I guess the rest of the data can just be stored as a long string in a 'description' column, perhaps?


Thanks for all the help guys, feel like such a newb.

[023-jimmy]

Well, just make a seperate table like somebody else said before. You have 1 table that holds the products and 1 table that hold the cart information.

So if your product table has a structure like this:
id | product_name | <other data>
Make the cart table like this:
id | userid | product_id

In the 'product_id' field (In the cart table) you put the id of the product.

[decowski]

But the way items are 'created' is down to the user. So each item is unique.
Just wondered how I then stored the item data in my 'cart' table before they check out?

Go get that coffe! I explained it before!

cart_item
---------
cart_item_id PK
product_id
...
...

cart_item_attributes
-------------------
cart_item_id FK
attribute
value

[john.smit00]

nice to see u havent lost ur sense of humour decowski

[Latox]

Why don't you store their sessions in a database under an IP and time(), then if they return in X time() their details will still be there - you can have a cron which deletes sessions from the database where they have not revisited in X days.

[023-jimmy]

Why don't you store their sessions in a database under an IP and time(), then if they return in X time() their details will still be there - you can have a cron which deletes sessions from the database where they have not revisited in X days.

Some people have an ip that changes every half hour or so. So this might not be the smartest way to do it. BUT, you could use it in combination with a cookie. So they can back each other up.

[trafficteam]

Thanks for providing such a great information.

[NikLP]

I can only assume you're nuts for even considering writing e-commerce from scratch. Suggested alternative:

1) Install Drupal
2) Install Ubercart package
3) Relax

Why would you want to write software yourself which *you* will have to support, when so many open source equivalents are doing it so well already?

[invision2]

Crikey, bit harsh.

Will Ubercart allow the customer to create their own products based on user input?