I'm working on a e-commerce website in PHP and I would like to implement the following feature: if a user is not logged in, he can add products to the shopping cart and still have those products after login. Also, the feature must work the other way around: a user is logging in and then he adds products to the shopping cart.
I thought that a good way to do this is by using the session id, but after doing some test it turned out that this isn't the best way to do it.
Any ideeas?
Why is using the session not the best way to do it? I'd say it is.
You could have a separate, session-based "non-logged in" shopping cart structure, an exact copy of the normal cart. If the user is not logged in, the products are stored there.
When the user logs in, you merge the non-logged in cart's contents with whatever items the user may already have in their user-speficic cart.
That point is also the place to deal with any conflicts that may arise from the product selection (like, a selected product being present in the logged in user's cart already).
Using cookies as recommended by #Codemwnci to either store the products, or a cart ID is a good idea too, because it allows the user to come back later and still have their cart contents, which you may want.
The same principle of merging will apply here as well, with an additional check whether the products in the cookie really are valid ones (they could have been removed since the user made their selection, or the user could have altered the cookie).
You can use cookies. Just store a unique identifier in the cookie, that represents the shopping basket. Regardless of whether the user is logged in or out, the Cookie identifier will still be the same, therefore the data will be persisted.
session_start();
$_SESSION["cartitems"] = "1,2,3";
Related
I have an ecommerce shop online using php, sql, javascript,ajax and sessions.
I have both guest and members cart options at checkout.
Everything works fine.
I store my cart items in a session currently.
Users can log in or have a guest cart.
Guests cart userids are referenced by the current session id.
members can login and their carts are referenced by their usersids from the database.
The problem is, the session expires after a certain amount of time and so the cart items are lost and the user has to start again.
On doing some research I have found that after the user logs in, I can store his user id in a cookie and I can specify how long that cookie lasts for which is ideal!
I am thinking of changing the code so that I store the items added to the cart in my database tables and simply reference them with the user id ive stored in his cookie.
That way He can shop for ages and not lose his cart and I can send abandon cart emails etc...
I think this would work well as nearly every website uses cookies so people have to have them enabled in their browser these days. I could show a warning message if cookies arent enabled anyway..
What does everyone think about this?
Please note I am not seeking security advice here.
I havent implemented this as yet - Im really looking to see if I can set my session lifetime to last a few hours/days instead.
I see your problem with Guest checkout and normal checkout after login.
You can go and use cookies rather than using sessions for this.
Cookie have setcookie() function with time() method.
You can set an Expiry time for that.
Go and use, it can help you
I'm developing a shopping cart for a website, and was wondering what way should I store the product id after the user has clicked on the "Add to cart".
Should I store them in a session -- Such as
$_SESSION['cart'][$productid]++;
Would this put strain on the server under load? Or is this the best way of doing it?
Or should I create a temp database table, store the information in there, and remove after order has been processed?
I would store them in a database for sure, but not create a temp table each time. I would suggest you keep a table that has all the unfinished orders along with an identifier for the user.
This will last longer than a session, all it to be retained after a user has logged off and available after that user logs back in again. When then user is logged in, keep their identifier in the session.
Edit: While connecting to a database does consume resources, that is what database servers are made for. A connection to a small table uses next to nothing - I mean, you are probably executing a good number of queries just displaying your shopping cart. If you get to the point where your website can't handle the extra stress due to saving an odd row in a small table, you will be getting enough money from the sales to buy a bigger server :)
You should definitely use a database table to store the items.
Logged-in users will appreciate that they didn't have to grab all items again, if they come back after some time!
You can keep the information of the cart in the session, to get the information you need, but you should set new information in the session and in the database!
And then before checkout you should cross-check your information.
Another advantage is that you can keep track of what is going on in your shop!
You wont have any information if no one buys your items and you store the carts in a session.
I'm writing a shopping car application and I would like visitors (i.e. people not logged in) to be able to add items to the shopping cart without logging in. Of course, they would be asked to log in if they wish to checkout. Currently I have it setup so that the shopping cart is associated with the persons user id on the site, but like I said I'd like to allow visitors to add items to the cart as well.
What would be the best approach to this problem?
Very simple: use sessions.
Presumably you're already doing that for logged in users, so you should know how they work. But sessions have nothing to do with being logged in, they can be used to simply accumulate information for any user.
I want to create an e-commerce project online. I have this issue :
if the user is not logged in, then the selected products will be automatically added to a default cart under the name of guest001, guest002 etc where guestxxx is a default user.
if the user signs up, then the system will automatically check in his carts data to add it to his new account
when the user then wants to add new products to cart, they will be added directly to his cart.
My questions are :
Should I be using cookies to store the data in the user's machine, so it will be used by the system once the user creates his account? or should I use server side session data?
Should I be creating a default client (guestxxx) in the database once the unknown user adds something to his cart, or just create a cookie to store the data without the need to create a guest user?
I just have little suggestion for you.
If you are using Codeigniter Framework you can use Library Cart Class
or you want make code yourself.
According to my experience. I was used session for store cart while users checkout I add his cart into my database.
Disadvantage of using it while browser is closed your guest cart will start from default (no cart),
If you use cookie for it while browser is closed your guest cart will keep exist. ( store in browser ). But I think you can use both of it. Use cookie for keep cart data and use session for processing cart in your PHP Code. because Cookie is stored in browser, malicious user can do malicious activity of it.
For client i think you can use session or cookie rather than add his data into database
Hope it can help you. I just know little about it.
I am in the process of making a website that involves a shopping cart.
There are two major requirements:
The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.
The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.
In the above context, I have the following question with respect to maintaining the cart's state:
Should I go with file based or database sessions? Please keep in mind this would be for unregistered users. My apprehension is that I'll end up having lots of records in the database.
Another option seems to be to put the cart contents in an encrypted cookie, but then there's a size limitation on the cookie file.
What would you do in this case ? I would really appreciate your answers.
Tracking a user. Use a GUID
encoded into a cookie with an
nYear expiry.
Storing a Shopping Bag. You don't want to store the bag in the cookie, mainly due its possible size. This leaves the option of persiting it to a medium and retrieving it from the medium. Using anything except a database for this would be like going back in time, databases excel at storing and retrieving data.
Managing you Shopping Bag. Now, the
question of your schema, firstly, if
your going to be running queries
against the shopping bags in the
database (i.e. how many shopping
bags contain item x) you probably
want a traditional relational
schema. However this has overheads
in terms of inserting. updating,
selecting (and joining) and deleting
bag data (at some point you'll have
bags that will never be used again
but are taking up precious disk
space). With a busy site, this is a
fair few Traranactions Per Second,
but any database should be able to
cope. If you don't need to query
the shopping bags in the database,
then you can store it as XML. Just
serialize the bag and dump it into a
table, with the PK as the GUID as
stored in the users cookie. This
would be a lot faster than a
traditional schema, plus you could
always tear apart the XML in the
future if a requirment did come up
for a relational schema.
This is what we do (Xml Bag), and we have a million+ customer base.
I would go with database managed sessions over file managed sessions. Make sure you have a session timestamp so that you can eventually kill old sessions (if it's been 12 months, the shopper is possibly not coming back for the items originally in the cart).
Doing this with a database instead of files will make it easier to eventually expire the very-old information.
Note that the database session will only ever be valid as long as the cookie it's tied to on the user's computer. If the user comes back to the store from a different browser, they will not find their session. If two people are sharing the same computer, they will find each other's session. Hopefully no potentially embarrassing items will be in the cart...
Store in cookies the AnonymousSessionID, with which you associate a shopping cart in the database.
Then you'll have a scheduler task to erase anonymous sessions after some time (say, a day). This will keep your database clean of abandoned sessions.
If a user registers, you reassociate their shopping cart with their account permanently. If the users makes an order, you empty their shopping cart.
If you're using ASP.NET here's what I'm (about) to do:
use a Profile to capture the users email as soon as possible (to email them if they dont complete the order). you can enable anonymous profile properties that are persisted to the aspnet database even if the user hasnt actually truly registered.
stick an XML bag representing an order into session. This is persisted in the database with a regular identity ID.
store the ID of the cart in the ASP.NET Profile. that way when the session expires you can just reload it from the ID in the profile. this has the benefit that the user never sees the cart ID in a cookie and you can easily link records between the membership/profile database and the store you're using for your orders
(dont try to store the XML order in the Profile. i think thats asking for performance issues. but in theory you could i suppose)
With those specs I would go with a database based session state. But you should do some heavy reading on how session state is handled in your web server of choice. Since you want to be able to revive the state to the correct person.
I think you have some expectations to manage, or maybe you weren't clear on requirements.
The user experience guys want login/authentication to be the very
last step in the entire work flow. The
user gets to do all the shopping and
is asked to login only at the time of
checking out.
The shopping cart shouldn't expire(not even on browser close)
unless the user (registered or not)
does check-out.
Specifically, an anonymous, not logged-in user's cart being saved? That's madness. Ensure that's not an expectation and clarify it in your design documents.