HI All,

Im a little confused as to the best way to approach the dealings with sessions when checking out, logging in, and logging out, in some cases the session can be written into the config file which is included in every page to help follow the user, however in other cases cookies are used until the checkout process, then the session starts, now what i am wanting to do is implement user registration on eCommerce which allows users to login and complete checkout but also give the option to checkout as a guest, without the user being registered,

my question is, whats the best way to track users? as logging in starts the session and logging out destroys the session, so if a user logs out will all items in cart be empty resulting in the user failing to be able to checkout?

any help or input would be much appreciated.

thanks guys! :)

Dani AI

Generated

Brief, practical answer for (and building on ’s point about understanding HTTP): do not tie cart lifetime solely to the PHP session. If the cart lives only in $_SESSION and logout calls session_destroy(), the cart will be lost. A reliable pattern is a server-side (database) cart identified by a persistent cart token cookie for guests and by user_id for logged-in users — this supports guest checkout, login/merge, and logout without emptying the cart.

Suggested workflow:

  • Guest visit: create a cart row and issue a long‑lived cart_token cookie. All add/remove operations update the DB cart_items table.
  • Login: call session_regenerate_id(true), locate the guest cart by cart_token, merge it with any existing user cart (sum quantities, resolve duplicates), then associate the merged cart with the user.
  • Logout: unset authentication fields and regenerate the session id, but keep the cart_token cookie and the DB cart intact. Avoid calling session_destroy() if the cart still lives in session; instead persist it to DB first.
  • Checkout: always revalidate product availability and prices server‑side and create the order from the DB cart; mark the cart as completed.

Example (pseudocode):

$token = $_COOKIE['cart_token'] ?? bin2hex(random_bytes(16));
setcookie('cart_token', $token, time()+30*24*3600, '/', '', true, true);
$guest = Cart::getOrCreateByToken($token);

session_regenerate_id(true);            // on login
$u = Cart::getByUser($user_id);
$merged = Cart::merge($u, $guest);
$merged->user_id = $user_id;
$merged->save();

unset($_SESSION['user_id']);           // on logout
session_regenerate_id(true);

Security/ops notes: use HTTPS, Secure/HttpOnly and SameSite cookies; never store payment credentials in cookies/sessions; recalc totals server‑side; implement expiry/cleanup for abandoned carts; use Redis or shared DB for multi‑server setups.

Recommended Answers

All 3 Replies

You really need to understand how http works under the hood for this kind of thing.

Its too much to cover in a textbox on a forum like this. You would be much better off spending some time watching some videos. This one for example is quite good:

https://www.youtube.com/watch?v=gav4HmZ8xe8

thanks daveamour, i do understand how cookies and sessions work however wanted to know of the best approach others would use for what i am trying to achieve, thanks for the link, its a good refresher.

Ok sorry my apologies.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.