The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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.

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.

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:

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.

Originally Posted by invision2

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.

Originally Posted by invision2

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.

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.

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.

Originally Posted by invision2

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.

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?

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

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

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?

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.

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.