SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 41
-
Feb 21, 2009, 10:29 #1
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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
-
Feb 21, 2009, 17:00 #2
- Join Date
- Aug 2005
- Location
- Winnipeg
- Posts
- 498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
The only constant in software is change itself
-
Feb 21, 2009, 17:27 #3
- Join Date
- Feb 2009
- Posts
- 14
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 21, 2009, 18:15 #4
- Join Date
- Jan 2009
- Posts
- 23
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.Last edited by 023-jimmy; Feb 21, 2009 at 19:42.
-
Feb 22, 2009, 10:32 #5
- Join Date
- Oct 2008
- Location
- London
- Posts
- 862
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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)Pawel Decowski (you should follow me on Twitter)
-
Feb 22, 2009, 11:00 #6
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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.
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:
Code:Jen's Car | 300miles | Petrol - 400GBP Mike's Car | 200miles | Petrol - 300GBP Paul's Bus | 250miles | Mini-Bus - 600GBP
Brilliant help so far, any further help would be much appreciated.
-
Feb 22, 2009, 11:17 #7
- Join Date
- Oct 2008
- Location
- London
- Posts
- 862
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You can just generate a unique ID for each guest and store it in a cookie.
Well, you’ve got it all in the database.
Use a separate table, eg:
Code:product_attribute ----------------- product_id product_attribute product_value
Pawel Decowski (you should follow me on Twitter)
-
Feb 22, 2009, 11:35 #8
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanks again for the reply Paul.
So in one of my include files I could have:
PHP Code: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;
}
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.
-
Feb 22, 2009, 11:42 #9
- Join Date
- Apr 2008
- Location
- North-East, UK.
- Posts
- 6,111
- Mentioned
- 3 Post(s)
- Tagged
- 0 Thread(s)
Just trying to figure out how I should store the data in the carts.
Just store a unique ID for the product, then on your cart display page, just query the DB for the necessary meta data.@AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.
-
Feb 22, 2009, 11:44 #10
- Join Date
- Oct 2008
- Location
- London
- Posts
- 862
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
Just as I explained above but relate the attribute to cart item rather than inventory item.Pawel Decowski (you should follow me on Twitter)
-
Feb 22, 2009, 11:51 #11
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
-
Feb 22, 2009, 11:56 #12
- Join Date
- Apr 2008
- Location
- North-East, UK.
- Posts
- 6,111
- Mentioned
- 3 Post(s)
- Tagged
- 0 Thread(s)
@AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.
-
Feb 22, 2009, 11:59 #13
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 22, 2009, 12:10 #14
- Join Date
- Jan 2009
- Posts
- 23
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-> 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.
PHP Code:mysql_query("INSERT INTO `cart` (`product_name`, `userid`) values('". $product ."', '". $_COOKIE['userid'] ."')");
PHP Code:mysql_query("SELECT * FROM `cart` WHERE `userid` = '". $_COOKIE['userid'] ."'");
You can create a login/register system..
-
Feb 22, 2009, 12:13 #15
- Join Date
- Mar 2004
- Location
- Kenneth City, FL
- Posts
- 823
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Feb 22, 2009, 12:18 #16
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Feb 22, 2009, 12:22 #17
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 22, 2009, 12:25 #18
- Join Date
- Jan 2009
- Posts
- 23
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 22, 2009, 12:27 #19
- Join Date
- Oct 2008
- Location
- London
- Posts
- 862
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
Code:cart_item --------- cart_item_id PK product_id ... ... cart_item_attributes ------------------- cart_item_id FK attribute value
Pawel Decowski (you should follow me on Twitter)
-
Feb 23, 2009, 03:19 #20
- Join Date
- Feb 2009
- Posts
- 13
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
nice to see u havent lost ur sense of humour decowski
-
Feb 23, 2009, 03:58 #21
- Join Date
- Dec 2008
- Location
- Australia
- Posts
- 389
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
:-)
-
Feb 23, 2009, 05:22 #22
- Join Date
- Jan 2009
- Posts
- 23
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Feb 23, 2009, 05:28 #23
- Join Date
- Feb 2009
- Posts
- 1
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanks for providing such a great information.
-
Feb 23, 2009, 09:43 #24
- Join Date
- Jul 2004
- Location
- Nottingham
- Posts
- 85
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?UK Drupal Architect & Consultant :: Kineta Systems
-
Feb 23, 2009, 09:46 #25
- Join Date
- Mar 2008
- Location
- United Kingdom
- Posts
- 1,285
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Crikey, bit harsh.
Will Ubercart allow the customer to create their own products based on user input?
Bookmarks