Shopping Cart Revision
Moderator: General Moderators
Shopping Cart Revision
Currently I have a working shopping cart based solely on Session Variables. I put Product IDs/Quantities in an array and store it in a session variable. It's simple and works fine. But, it has some limitations and negative aspects that aren't allowing me to expand the usability of the site.
If the server needs to be rebooted or crashes, items in their cart get wiped out. Also, because I can only store a Product ID and it's quantity, I can't do more with their shopping experience. I want to have automatic discounts based on what they put in their cart. Things like, buy any item from this category and any item from that category, and get 10% off. This is impossible with only a ProductID/Quantity array combination.
So... I want to implement a new shopping cart. I'm hoping for some feedback as to whether or not my idea sounds good. Please let me know if you see any flaws with my plan.
I plan on using a Database driven cart, but without the user being forced to log in. That's another aspect I really want to keep. I do not require users to log in or have an account to make a purchase, it's totally optional.
So, my database would consist of a UserID, productID, Quantity, TimeStamp, and other columns used for advanced cart options (for discounts, etc).
The User ID would be either the visitor's SessionID (if not logged in) or their Account ID (if logged in). So, at least logged-in customers would not lose their item list if the server was restarted. After each order, the cart database would be cleaned by removing the items from that order. Also, for users who are not logged-in (aka "session ID" users), those items which were added more than X hours ago would also be deleted. So, it would keep "Account ID" users' items, maybe for a limited time also though.
I only have one issue that may cause some problems. If an existing user comes to my site, starts shopping, and logs in later... he may already have old items from previous sessions. So, I'd have to send a message asking if he still wants those. Or I could automatically put older Account User items in a "wishlist" instead of the cart.
Please let me know what you think of this shopping cart idea. All feedback is welcome.
If the server needs to be rebooted or crashes, items in their cart get wiped out. Also, because I can only store a Product ID and it's quantity, I can't do more with their shopping experience. I want to have automatic discounts based on what they put in their cart. Things like, buy any item from this category and any item from that category, and get 10% off. This is impossible with only a ProductID/Quantity array combination.
So... I want to implement a new shopping cart. I'm hoping for some feedback as to whether or not my idea sounds good. Please let me know if you see any flaws with my plan.
I plan on using a Database driven cart, but without the user being forced to log in. That's another aspect I really want to keep. I do not require users to log in or have an account to make a purchase, it's totally optional.
So, my database would consist of a UserID, productID, Quantity, TimeStamp, and other columns used for advanced cart options (for discounts, etc).
The User ID would be either the visitor's SessionID (if not logged in) or their Account ID (if logged in). So, at least logged-in customers would not lose their item list if the server was restarted. After each order, the cart database would be cleaned by removing the items from that order. Also, for users who are not logged-in (aka "session ID" users), those items which were added more than X hours ago would also be deleted. So, it would keep "Account ID" users' items, maybe for a limited time also though.
I only have one issue that may cause some problems. If an existing user comes to my site, starts shopping, and logs in later... he may already have old items from previous sessions. So, I'd have to send a message asking if he still wants those. Or I could automatically put older Account User items in a "wishlist" instead of the cart.
Please let me know what you think of this shopping cart idea. All feedback is welcome.
shopping cart
Hi,
I'm new to PHP stuff and I don't have too much time to spend on this stuff right now but I thought it'd be a good idea to take a good look at those shopping card programs. I never used one, as I said I'm new to this, but I believe it may help you understand what you need to do next, who knows.
There are some good programs that I heard, one of them is OScommerce, freely distributed @ http://www.oscommerce.com. Check it out maybe it helps for your code.
Sorry, couldn't help more.
I'm new to PHP stuff and I don't have too much time to spend on this stuff right now but I thought it'd be a good idea to take a good look at those shopping card programs. I never used one, as I said I'm new to this, but I believe it may help you understand what you need to do next, who knows.
There are some good programs that I heard, one of them is OScommerce, freely distributed @ http://www.oscommerce.com. Check it out maybe it helps for your code.
Sorry, couldn't help more.
I'm not looking for code, I'll do that myself. I'm looking for feedback on my plan, from a conceptual point of view. I appreciate the response though.
I looked at some of those a long time ago, and they do a lot of stuff I didn't need them to do, and didn't do a lot of stuff I did need. So, I made my own, customized shopping cart.
I looked at some of those a long time ago, and they do a lot of stuff I didn't need them to do, and didn't do a lot of stuff I did need. So, I made my own, customized shopping cart.
-
The Monkey
- Forum Contributor
- Posts: 168
- Joined: Tue Mar 09, 2004 9:05 am
- Location: Arkansas, USA
I have no idea how large of a website you are designing, or how many users you expect, but another option would be to have a shopping cart table in the database, like this:Swede78 wrote:I'm not looking for code, I'll do that myself. I'm looking for feedback on my plan, from a conceptual point of view. I appreciate the response though.
I looked at some of those a long time ago, and they do a lot of stuff I didn't need them to do, and didn't do a lot of stuff I did need. So, I made my own, customized shopping cart.
++++++++++++++++++++++++++++++++++
+ productID + shopperID + lastUpdated + quantity +
++++++++++++++++++++++++++++++++++
You would have one entry for each item in the shoppers cart, and the lastUpdated would be a Unix Timestamp that is updated on each page refresh by that Shopper. You could delete all of the items in the shopping cart that haven't been updated in, say, 15 minutes.
I've never created a Shopping Cart system, but that's my take on it.
To answer your first question, Monkey, the site is up and running, and last week, we averaged about 3000 visits a day. I appreciate your suggestion, however, it's basically the exact same thing as what I described I was planning on doing.I have no idea how large of a website you are designing, or how many users you expect, but another option would be to have a shopping cart table in the database, like this:
++++++++++++++++++++++++++++++++++
+ productID + shopperID + lastUpdated + quantity +
++++++++++++++++++++++++++++++++++
So, I guess you agree then that that would be a good way to go. Thanks for the response.So, my database would consist of a UserID, productID, Quantity, TimeStamp, and other columns used for advanced cart options (for discounts, etc).
Maybe someone out there has done a cart in a similar manner. I'm not looking for anyone to provide code for me. This is a question about overall design, and how well it will work. Has someone tried this already and found it to be very slow or have a lot of problems? Would I be wasting my time attempting this? Or does it sound like a good idea?
I'll explain my plan here again, short and sweet:
I plan to use a database to store each item. Each entry will include an identity field, which would be either the customer's account ID if they're logged in, or a PHP Session ID if they're not logged in. I'll clean up the database after each order is placed. (ie.: delete items of non-logged-in users after X amount of time.)
One of my biggest concerns is how well the session ID thing will work. I've seen many articles where people don't seem to trust them as being unique. I've never found it to be a problem, but have never stored them in a database either. Maybe I should use my own ID generator and store them on the customers computer with a cookie.
Please, any feeback on the design would be appreciated.
I find this interesting... It seems like people don't like to answer questions or help people who are designing retail websites. The only other time I've asked for help and mentioned that it is for a store, I got no response. I can understand that if someone comes on here and says "I want to create an online store, gimmee the code", that nobody's going to do the work for them.
Maybe this post belongs under another topic. "Theory and Design" seemed to be the ideal topic, as I'm asking about design issues and not code. But, maybe this section was reserved for the highly abstract and philosophical discussions. I figured my post would have been moved here if I posted it under "Code". Maybe I'll post it there, since it's the more travelled section.
There's gotta be other people out there who design real world, retail websites. Does everyone just use those pre-made carts?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I would not use the SessionID as the userID. I would leave the userID blank (or 0). Instead I would store the record ID for the cart record in the User's session. I also recommend having a single cart record in one table, and multiple cart item records in a second table. Each cart item record contains the cart record ID
(#10850)
Arborint,
Thank you for the response. As for splitting up the cart into 2 tables. Good point, I'll do that. I'm all for relational database design. I do that now to store orders. I just over-simplified my database structure in my post.
As for not storing the SessionID as a UserID... I'm assuming that this would be for a security concern? Or maybe to ensure that there are no duplicate UserIDs. If I'm missing the real reason, would you mind explaining what the advantage would be?
Thank you for the response. As for splitting up the cart into 2 tables. Good point, I'll do that. I'm all for relational database design. I do that now to store orders. I just over-simplified my database structure in my post.
As for not storing the SessionID as a UserID... I'm assuming that this would be for a security concern? Or maybe to ensure that there are no duplicate UserIDs. If I'm missing the real reason, would you mind explaining what the advantage would be?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
For me the sessionID is a transient thing. The recordID of the cart is the cart. For example you could store the recordID in a cookie and a user could come back and see their cart even if their sessionID had changed.As for not storing the SessionID as a UserID... I'm assuming that this would be for a security concern? Or maybe to ensure that there are no duplicate UserIDs. If I'm missing the real reason, would you mind explaining what the advantage would be?
I see matching the session to the cart as seperate to matching the cart userID back to a user record. If it is blank or 0 that clearly says there is no user associated with this cart recrod.
I see... that's a good idea. Thank you arborint! I think I'll do a combination of sessions, cookies, and database.
Here's my revised plan:
Database Table 1 - "shopping_cart":
CartID | UserID (Customer Account ID or NULL) | LastUpdate (TimeStamp)
Database Table 2 - "shopping_cart_items":
CartID | ProductID | Quantity | other fields needed for extra shopping features (not planned out yet)
When viewing or updating their cart, I'll first check the "shopping_cart" for the UserID of the shopper, if they're logged in. If not logged in, then I'll check the session for a CartID. And if that doesn't contain it, then look at the cookie last. If they don't have any of these, they will be created. If they have a cookie with a CartID that is still valid, but no session variable, then I'll recreate the session variable. I'll maybe make this valid for a day or two. If they're logged in, then I will not use sessions or cookies for this.
I think what I'll do with "old" data for records that have a UserID, is move those items to a wishlist table if it's been there for over a day or so.
I probably need to encrypt their CartID if it's stored in a cookie. Otherwise, they could just change a number in it and they'd suddenly be able to modify someone elses cart. I doubt this would happen, but it's possible someone could try messing with the site this way. That's my only concern for using cookies. It shouldn't cause too much stress on the server processing this, as I'll only need to do encryptions/decryptions when the cookie is being made and only when it's the last resort to read.
Obviously this isn't a super-detailed plan, but this is what I was trying to accomplish for now. An idea of how to improve my very basic shopping cart.
Here's my revised plan:
Database Table 1 - "shopping_cart":
CartID | UserID (Customer Account ID or NULL) | LastUpdate (TimeStamp)
Database Table 2 - "shopping_cart_items":
CartID | ProductID | Quantity | other fields needed for extra shopping features (not planned out yet)
When viewing or updating their cart, I'll first check the "shopping_cart" for the UserID of the shopper, if they're logged in. If not logged in, then I'll check the session for a CartID. And if that doesn't contain it, then look at the cookie last. If they don't have any of these, they will be created. If they have a cookie with a CartID that is still valid, but no session variable, then I'll recreate the session variable. I'll maybe make this valid for a day or two. If they're logged in, then I will not use sessions or cookies for this.
I think what I'll do with "old" data for records that have a UserID, is move those items to a wishlist table if it's been there for over a day or so.
I probably need to encrypt their CartID if it's stored in a cookie. Otherwise, they could just change a number in it and they'd suddenly be able to modify someone elses cart. I doubt this would happen, but it's possible someone could try messing with the site this way. That's my only concern for using cookies. It shouldn't cause too much stress on the server processing this, as I'll only need to do encryptions/decryptions when the cookie is being made and only when it's the last resort to read.
Obviously this isn't a super-detailed plan, but this is what I was trying to accomplish for now. An idea of how to improve my very basic shopping cart.
i use a purely session based cart, and ive had no problems with it. its very fast, and i went this route because its just so damn portable, if youve got sessions, youve got a working cart. and with it being in a class, using it is extremely easy.
the thing you need the keep in mind is that if you use it with sessions, everytime that user loads a page, if you start/continue a session, php must load and parse the data. but a shopping cart is really a fairly simple thing, and the amount of data needed to be loaded is pretty small. I suppose if you kept stuff like very long item descriptions and the like in the session, it could start to drag things down, but not much.
i just did not see benefits outweighing drawbacks to using a database, unless, i want to keep their records, such as if they signed up for an account, or something like that where i would want to retrieve info later.
if youd like to look at some code for ideas, ill strip it down to the relevant stuff and post it.
the thing you need the keep in mind is that if you use it with sessions, everytime that user loads a page, if you start/continue a session, php must load and parse the data. but a shopping cart is really a fairly simple thing, and the amount of data needed to be loaded is pretty small. I suppose if you kept stuff like very long item descriptions and the like in the session, it could start to drag things down, but not much.
i just did not see benefits outweighing drawbacks to using a database, unless, i want to keep their records, such as if they signed up for an account, or something like that where i would want to retrieve info later.
if youd like to look at some code for ideas, ill strip it down to the relevant stuff and post it.
I do appreciate the feedback, but I have a working shopping cart using sessions right now. I do agree that it's quick and has been very good for my first cart. Now, I want to improve it. I like the idea of people not losing their cart items when they close their browser or the site gets restarted (not very often that the 2nd situation happens, but still).
The main reason I'm looking to go to a database/session/cookie cart system, is so I can add features that I just can't with a session-only based cart. I need to store more info per item than I can with sessions - where I use arrays (productID/quantity). The features I'm going to add are things like: "Buy 1 item from this category and pick 2 free items from this categort". I haven't fully planned out how these features will work. But it won't work only being able to store productID and quantity. It would be way to much work to look at every combination of the customer's cart to see what discounts they qualify for. Then if they have items that would fall under multiple discount offers, it would just complicate and stress things too much.
What information do you store in sessions?
The main reason I'm looking to go to a database/session/cookie cart system, is so I can add features that I just can't with a session-only based cart. I need to store more info per item than I can with sessions - where I use arrays (productID/quantity). The features I'm going to add are things like: "Buy 1 item from this category and pick 2 free items from this categort". I haven't fully planned out how these features will work. But it won't work only being able to store productID and quantity. It would be way to much work to look at every combination of the customer's cart to see what discounts they qualify for. Then if they have items that would fall under multiple discount offers, it would just complicate and stress things too much.
What information do you store in sessions?
you could manipulate session cookie's parameters via [php_man]session_set_cookie_params[/php_man]Swede78 wrote:I like the idea of people not losing their cart items when they close their browser...
with default file based sessions that should not be an issue unless server cleans its temporary files during startup sequence.Swede78 wrote: or the site gets restarted (not very often that the 2nd situation happens, but still).
It's not that I think your idea bad or something... just pointing out that sessions is powerful and flexible tool and should not be underestimated.
Well, I do use the default file-based sessions. So, if that's true, I guess the server crashing/restarting may not be an issue with wiping out sessions. It's more of a concern to me that the whole site is down rather than the customer's items are wiped out. That and the fact that it's pretty rare that it even happens, it's of little concern.with default file based sessions that should not be an issue unless server cleans its temporary files during startup sequence.
As for manipulating session cookie parameters, I'll have to try that out. I wasn't aware that you could extend the life of the session cookies. However, if the session garbage collection timeout is shorter than how long I want the session cookie to last, that would be a problem too. I'll have to look in to it.
Thanks for the suggestion.
Good point, I didn't think about it partly because I was under impression that you have control over the server's configuration. BTW there's another feature of PHP sessions you might not be aware of: Custom Session Handlers implemented via [php_man]session_set_save_handler[/php_man]. It allows you to store session data into db, decide what to do when garbage collector is ran and much more...Swede78 wrote: As for manipulating session cookie parameters, I'll have to try that out. I wasn't aware that you could extend the life of the session cookies. However, if the session garbage collection timeout is shorter than how long I want the session cookie to last, that would be a problem too.
Actually it is now on a dedicated server, but I didn't always have that luxury. I wrote that because I figure that most people are on shared servers, who may not be able to do that. So, I will definitely look into the session cookie parameters. But, I still may want the visitors cart data stored much longer than I want the garbage collection to run. I may want to store cart data for a week. But, that seems too long for the GC to run. I don't know how long the average store keeps your cart data, but I think I've gone to Amazon months after my latest visit and had everything still there.
I read a lot of articles about the mysql session handlers when I started building my current cart, so I am aware of that possibility. But, I also noticed that there were a lot of complications with it. The default PHP session handler seems to work well. Since I don't store any sensitive info in them without encryption, and I don't foresee ever needing to move to multiple servers, I'm just not convinced that the amount of work involved in creating it is worth it.
Are you recommending building a custom session handler and incorporating the cart into it somehow? Because it seems to me that a custom session handler wouldn't make it easier to build a database driven shopping cart, since they would still be separate components.
I read a lot of articles about the mysql session handlers when I started building my current cart, so I am aware of that possibility. But, I also noticed that there were a lot of complications with it. The default PHP session handler seems to work well. Since I don't store any sensitive info in them without encryption, and I don't foresee ever needing to move to multiple servers, I'm just not convinced that the amount of work involved in creating it is worth it.
Are you recommending building a custom session handler and incorporating the cart into it somehow? Because it seems to me that a custom session handler wouldn't make it easier to build a database driven shopping cart, since they would still be separate components.